An Organisational Perspective on Collaborative Business Processes

Transcription

1 An Oranisational Perspective on Collaborative Business Processes Xiaohui Zhao, Chenfei Liu, and Yun Yan CICEC - Centre for Internet Computin and E-Commerce Faculty of Information and Communication Technoloies Swinburne University of Technoloy Melbourne, VIC 322, Australia {xzhao, cliu, yyan}@it.swin.edu.au Abstract. Business collaboration is about coordinatin the flow of information amon oranisations and linkin their business processes. It brins reat challene to keep participatin oranisations as autonomous entities in interatin business processes of these oranisations seamlessly. To address this issue, we develop a new perspective on business collaborations with a novel concept called relative workflow, which defines what a participatin oranisation can perceive in collaboration. By incorporatin a visibility control mechanism, relative workflows allow each oranisation to define its own collaboration structure and behaviours. In this paper, we present a formal definition of relative workflows and related alorithms for eneratin relative workflows, alon with a discussion on how to perform trackin over relative workflows. Introduction Recent years have seen the trend of lobal business collaboration urently requirin oranisations to dynamically form virtual oranisation alliances. The business processes of different oranisations need to be interated seamlessly to adapt the continuously chanin business conditions and to stay competitive in the lobal market []. To enable such business collaboration, research efforts have been put on improvin current workflow technoloies for supportin collaborative business processes [2-6]. Web service technoloy has also emered partly for this purpose and has been deployed for implementin inter-oranisational workflows [7,8]. Current inter-oranisational workflow approaches mainly focus on modellin workflows from a public view, where a third-party desiner or the leadin oranisation of a virtual oranisation alliance defines the business collaboration structure and behaviours by choosin participatin oranisations and linkin workflow processes of these oranisations into an inter-oranisational workflow process. These approaches work well with the assumption that there exists a thirdparty desiner or a leadin oranisation that can see certain level of details of all participatin oranisations. However, this assumption is too restrictive. Thouh several oranisations may be involved in the same collaborative business process for

2 2 Xiaohui Zhao, Chenfei Liu, and Yun Yan a defined business oal, the relationship between each pair of participatin oranisations could be different. As such, the visibility between participatin oranisations may be relative, rather than absolute as adopted in the public view approaches. Besides, the predominant view of a third-party desiner or a leadin oranisation may put participatin oranisations in a passive position. This violates that each participatin oranisation acts as an autonomous entity in business collaboration. Moreover, the pre-fixed business collaboration in the public view approaches may not be applicable to those applications where the partner relationship is not fixed. Aimin at solvin these problems, we develop a new perspective on business collaboration based on a novel concept called relative workflow, to support participatin oranisations as autonomous entities. A collaborative business process is represented as a series of relative workflow processes, each of which is defined from the perspective of an individual participatin oranisation. This allows each oranisation, as an autonomous entity, to desin its own collaboration structure and behaviours. The third party or leadin-oranisation-oriented inter-oranisational workflow desin can be distributed into multiple one-party oriented relative workflow process desin. Different visibility constraints can then be defined for different oranisations to reflect the fine ranularity of visibility control between participatin oranisations. The remainder of this paper is oranised as follows. In Section 2, we analyse, with a motivatin example, the business collaboration requirements that are not well supported by current approaches. Section 3 presents the formal definitions relevant to relative workflow processes. Section 4 introduces a procedure and alorithms for eneratin relative workflow processes. Section 5 addresses how to perform workflow trackin amon oranisations. Section 6 discusses the advantaes of relative workflows and their applied domains. Related work and concludin remarks are iven in Section 7 and Section 8, respectively. 2 Requirement Analysis with Motivatin Example Traditional inter-oranisational workflow desin approaches streamline business processes contributin to a common business oal, yet belonin to different oranisations, into a public workflow process. As discussed earlier, this procedure has the followin problems. The first problem is that the collaboration choreoraphy of all participatin oranisations is determined by a third party desiner or a leadin oranisation. Followin this approach, each oranisation behaves in the collaboration passively as a worker does in a pipeline workshop. We find that in many cases, a participatin oranisation expects to choose its own partner oranisations and define interoranisational workflow processes by itself to adapt its own collaboration objectives and benefits rather than deleate to a third-party desiner or a leadin oranisation. Actually, it is not always possible to find an appropriate third party desiner or a leadin oranisation.

3 An Oranisational Perspective on Collaborative Business Processes 3 The second problem is the coarse ranularity of visibility control. As the public inter-oranisational workflow process is open to each involved oranisation, either excessive information has to be disclosed or required collaboration information is not provided sufficiently. In the former, some private business information may be disclosed unwillinly to an involved oranisation with a distant partner relationship. In the latter, business processes belonin to involved oranisations cannot be interated seamlessly. The third problem may be caused by pre-determined collaboration choreoraphy of participatin oranisations. This may not be applicable to some business collaboration scenarios, where the partner relationship between participatin oranisations may be chaned in an ad hoc manner. We believe that business collaboration should be decided from the view of each individual oranisation, i.e., an oranisation defines its collaboration structure and behaviours by followin correspondin contracts with proper partner oranisations, and may chane them later by updatin existin contracts or sinin new contracts. In this way, each oranisation acts as a hihly autonomous collaboration participant. Shipper Supplier (Product Orderin) (Production) (Shippin) (Supplyin) Raise Order Order Parts Place Order with Production Customer Check Inventory Book Van Preparation Pay Approve Payment Print Cheque Make Goods Dispatch Goods DB Stock Parts Check Arrival Pay Supplier (Inventory Manaement) Fi.. Inter-oranisational workflow process example (modified from [9]) Fiure shows business collaboration amon a retailer, a manufacturer, a shipper and a supplier, from a public view. Five intra-oranisational workflow processes and their interaction are shown in the fiure. When a Product Orderin process of a retailer sends a product order to a manufacturer, the Production process of the manufacturer may hold this order until it has collected enouh orders from more than one Product Orderin process for the purpose of batch production. Before it starts producin products, the manufacturer needs to order necessary parts from suppliers, which will interact with the Inventory Manaement process of the manufacturer later for arrival checkin and invoice/payment processin. Also, the manufacturer needs to contact shippers to book the delivery of products, and simultaneously checks inventory with the Inventory Manaement process throuh the corporate database

4 4 Xiaohui Zhao, Chenfei Liu, and Yun Yan within the same oranisation. Finally, the retailer receives the products from the shipper, and pays the invoice to the manufacturer. In this example, all the participatin oranisations have the lobal knowlede of the whole collaboration process, which is somehow pre-determined and may be defined by a third party desiner or a leadin oranisation such as the manufacturer. Once the collaborative process has been defined, each participatin oranisation acts passively and loses more or less its autonomy. It will be difficult for an oranisation to chane its collaboration structure and behaviours, for instance, to start a new partner relationship or to terminate an existin partner relationship. Besides, the lobal knowlede of the whole collaboration process ives no chance to define a close or distant partner relationship between participatin oranisations. For example, from Fiure, we can clearly see that the views from a retailer and a manufacturer on the collaborative process are different. While a manufacturer has a close partner relationship with all other participatin oranisations, a retailer, however, only has a close partner relationship with a manufacturer via a proper purchase/supply contract. A retailer may not need to know, and actually should not know the manufacturer s partner relationships, say, with a supplier. At the same time, a retailer may need to have some knowlede about a shipper of the manufacturer so that trackin on the delivery of products may be made possible. We may also need to allow that a manufacturer chanes partner relationships with suppliers and shippers for better services. All these are not well supported in the public view approaches. In this paper, we propose a new approach to enable the participatin oranisations as autonomous entities. The different views from individual oranisations are well supported by the concept of relative workflows. This approach also provides visibility control with the finer ranularity and allows the easy chane of partner relationships in business collaboration. 3 Relative Workflow Processes In this section, we define a relative workflow, which is based on a visibility control mechanism, to support the requirements discussed in Section 2. In our context, a collaborative workflow process consists of several intra-oranisational workflow processes of participatin oranisations and their interaction. We call these intraoranisational workflow processes as local workflow processes. Definition (Local Workflow Process) A local workflow process lp is defined as a directed acyclic raph ( T, R ), where T is the set of nodes representin the set of tasks, and R T T is the set of arcs representin the execution sequence. Definition 2 (Oranisation) An oranisation is defined as a set of local workflow processes {lp, lp 2,, lp n }. An individual local workflow process lp i of is denoted as.lp i. As the owner of local workflow processes, a participatin oranisation may wish to protect the critical or private business information of some workflow tasks from disclosin to other participatin oranisations, durin business collaboration. Accordin to the two most important behaviours in the context of collaborative

5 An Oranisational Perspective on Collaborative Business Processes 5 workflows, i.e. workflow trackin and business interaction, we define the followin three values for the visibility of workflow tasks as listed in Table. Table. Visibility values Visibility value Explanation Invisible A task is said invisible to an external oranisation, if it is hidden from that oranisation. Trackable A task is said trackable to an external oranisation, if that oranisation is allowed to trace the execution status of the task. Contactable A task is said contactable to an external oranisation, if the task is trackable to that oranisation and the task is also allowed to send/receive messaes to/from that oranisation for the purpose of business interaction. Definition 3 (Visibility Constraint) A visibility constraint vc is defined as a tuple (t, v), where t denotes a workflow task and v { Invisible, Trackable, Contactable }. A set of visibility constraints VC defined on a workflow process lp is represented as a set {vc:(t, v) t (t lp.t )}. Example. Based on Fiure, two sets of visibility constraints are iven as follows: VC = { ( Raise Order, Invisible), ( Place Order with, Contactable), ( Customer, Contactable), ( Pay, Contactable), ( Approve Payment, Invisible}), ( Print Cheque, Invisible)}. VC 2 = { (, Contactable), ( Order Parts, Invisible), ( Production, Trackable), (, Trackable), (, Contactable), ( Check Inventory, Invisible), ( Make Goods, Trackable), ( Dispatch Goods, Trackable), (, Contactable)}. These two sets are defined on the Product Orderin and Production processes, respectively. lp Definition 4 (Perception) A perception p. of an oranisation s local workflow process lp from another oranisation is defined as ( VC, MD, f ), where VC is a set of visibility constraints defined on.lp. MD M { in, out }, is a set of the messae descriptions that contains the messaes and the passin directions. M is the set of messaes used to represent inter-oranisational business activities. f: MD.lp.T is the mappin from MD to.lp.t, and.lp is the perceivable workflow process of.lp from. The eneration of.lp from.lp will be discussed in the next section. Example 2. Aain, based on Fiure, the perception of the retailer s Product Orderin process from the manufacturer, and the perception of the manufacturer s Production process from the retailer are iven, respectively, as follows: retailer. productorderin p = ( VC, {( Order of Products, out), ( ation of Date, in), (, in) }, {( Order of Products, out) Place Order with, ( ation of Date, in) Customer, (, in) Pay } );. production p retailer = ( VC 2, {( Order of Products, in), ( ation of Date, out), (, out) },

6 6 Xiaohui Zhao, Chenfei Liu, and Yun Yan {( Order of Products, in), ( ation of Date, out), (, out) } ). where VC and VC 2 are defined in Example. Definition 5 (Relative Workflow Process) A relative workflow process.rp perceivable from an oranisation is defined as a directed acyclic raph ( T, R ), where T is the set of the tasks perceivable from, which is a union of the followin two parts: k. lp. T, the union of the task sets of all.lp k. k j, the union of the task sets of all perceivable workflow processes of. lp i j i. T i.lp j from. R is the set of arcs perceivable from, which is a union of the followin three parts: k lp. R, the union of the arc sets of all.lp k. k. j i. lp. R, the union of the arc sets of all perceivable workflow processes of i j i.lp j from. L, the set of messain links between local and perceivable workflow processes, consistin of two parts: L intra, the set of intra-oranisational messain links that connect tasks belonin to different local workflow processes, and is defined on i j U U. lp. T. lp.t where i j. i j L inter, the set of inter-oranisational messain links that connect tasks between a local workflow process and a perceivable workflow process, and is defined on k j j k U UU(. lp. T i. lp. T i. lp. T.. T ) lp. i j k Relative Workflow Process Relative Workflow Process has has has [, n] Local Wf Process composes [, n] Visibility Constraints [, n] has [,n] Messae Link Set Perception [, n] Preceivable Wf Process [, n] Messae Description [, n] has has has has [, n] [,n] [, n] Preceivable Wf Process Messae Link Set Local Wf Process composes match [, n] [, n] Messae Description [, n] Visibility Constraints [, n] has Perception has Fi.2. Relative workflow model

7 An Oranisational Perspective on Collaborative Business Processes 7 Fiure 2 illustrates how the components of the relative workflow model are related across oranisations. Given the discussion and definition of the relative workflow process above, a necessary procedure for an oranisation, or, to enerate relative workflow processes is to define the perceptions on local workflow processes. This step includes definin visibility constraints, messae links and matchin functions. Once the perceptions on local workflow processes of its partner oranisations have been defined, a relative workflow process can be enerated by two more steps: composin tasks and assemblin relative workflow processes. The purpose of composin tasks is to hide some private tasks of local workflow processes. We choose to mere invisible tasks with the contactable or trackable tasks into composed tasks, if not violatin the structural validity; otherwise, those invisible tasks are combined into a dummy task. Accordin to the perception defined from, a local workflow process of after this step becomes a perceivable workflow process for. In the step of assemblin relative workflow processes, an oranisation, say, assembles its local workflow processes with perceivable workflow processes from its partner oranisations, say, into a relative workflow process, as shown in Fiure 2. The details are to be discussed in the followin section. 4 Generatin Relative Workflow Processes 4. Definin Perceptions A perception can be derived by analysin and decomposin a commercial contract between oranisations in connection to certain business collaboration. Unlike a contract, a perception is defined from the perspective of one oranisation on the local workflow processes of other participatin oranisations. To represent a business interaction between an oranisation and other participatin oranisations,, m, two sets of such perceptions are required: PS, the set of the perceptions defined on.lp,, p n. lp m n lp from,, m, i.e. {..lp p,,. lp n p,,.lp m p,, }; and PS 2, the set of the perceptions defined on all local workflow processes.lp n. lp.lp nm m lp p. of,, m from, i.e. { p,, p,, p m,, }. Fiure 3 shows the Product Orderin process and the Production process in Fiure, where the dashed arrows denote the messae descriptions. To represent the business interaction between these two processes, we can define the perception.productorderin p of the retailer s Product Orderin process from the manufacturer. production and the perception p of the manufacturer s Production process from the retailer, which are already iven in Example.

8 8 Xiaohui Zhao, Chenfei Liu, and Yun Yan ( Product Orderin ) ( Production ) Raise Order Order of Products Place Order with Order of Products Order Parts Production Customer ation of Check Inventory Pay Approve Payment ation of Make Goods Dispatch Goods Print Cheque Fi. 3. Local workflow processes 4.2 Composin Tasks In this step, a local workflow process needs to hide its invisible tasks by composin them with proper contactable or trackable tasks for creatin the correspondin perceivable workflow process. The alorithm is iven below. For the simplicity of discussion, we only consider composin one local workflow process lp of the oranisation from another oranisation. Furthermore, we conduct a pre-processin on all split/join structures of lp such that for all those branches consistin of only invisible tasks, a dummy task is created to deleate these branches. Alorithm. Task Composition Input: lp =.lp, the oranisation s local workflow process lp before composition p = lp, the perception of s lp from p. Output: lp =.lp, the perceivable workflow process composed from lp for, accordin to lp = lp; VT = { all the visible tasks of lp, defined in p}; // connect invisible tasks while ( t, t (lp.t VT)) ((t, t ) lp.r ) seq(t) seq(t )) // seq(t)=(inderee(t)= outderee(t)=) { t =t+t ; lp.t = lp.t {t }-{ t, t }; lp.r = lp.r-{( t, t )}; replace t, t in lp.r with t ; } // downward composition with incomin interaction tasks while (( t VT (p.f - (t)=(m, in) outderee(t) =) ( t (lp.t-vt))((t, t ) lp.r inderee(t )=)) lp p..

9 An Oranisational Perspective on Collaborative Business Processes 9 { t =t+t ; VT= VT {t }-{t}; lp.t = lp.t {t }-{t, t}; lp.r = lp.r-{(t, t )}; replace t, t in lp.r with t ; } // upward composition with outoin interaction tasks while (( t VT (p.f - (t)=(m, out) inderee(t) =) ( t (lp.t-vt))((t,t) lp.r outderee(t )=)) { t =t+t ; VT= VT {t }-{t}; lp.t = lp.t {t }-{t, t}; lp.r = lp.r-{(t, t)}; replace t, t in lp.r with t ; } Alorithm first keeps composin each pair of neihbourin sequential invisible tasks into one invisible task, then downward composes invisible tasks with incomin interaction tasks and upward composes invisible task with outoin interaction tasks. Fiure 4 shows the results of task composition: (a) is the perceivable Product Orderin process of the retailer from the manufacturer; and (b) is the perceivable Production process of the manufacturer from the retailer, where the dashed rectanles denote invisible tasks. ( Product Orderin ) ( Production ) Raise Order Order of Products Order Parts Place Order with Order of Products Production Customer ation of Pay Check Inventory Approve Payment ation of Make Goods Print Cheque Dispatch Goods Fi. 4. Perceivable workflow processes ( a ) ( b )

10 Xiaohui Zhao, Chenfei Liu, and Yun Yan 4.3 Assemblin Relative Workflow Processes In this step, proper local workflow processes and perceivable workflow processes are connected toether by linkin the correspondin interaction operations. This can be achieved by matchin the messae descriptions defined in the perceptions, usin the alorithm below. Similarly, for the simplicity of discussion, we only consider matchin one local workflow process lp of the oranisation from another oranisation. Alorithm 2. Local Workflow Process Matchin Input: lp' =.lp, the perceivable workflow process composed from s local workflow process lp. lp p = p., the perception of s lp from ps = {.lp p,,. lp p n }, the set of perceptions defined on s perceivable workflow processes from Output: L, the set of enerated messain links L = ; for each t lp.t if md( p.f - (md)= t) then { md =p.f - (t); for each p ps for each md 2 p.md if md matches md 2 then L = L {(t, p.f(md 2 ), md )}; } ( Product Orderin ) ( Production ) ( Product Orderin ) ( Production ) Raise Order Place Order with Customer Pay Send Order Production Make Goods Place Order with Customer Send Order Order Parts Production Check Inventory Make Goods Approve Payment Dispatch Goods Pay Dispatch Goods Print Cheque ( a ) ( b ) Fi. 5. Relative workflow processes

11 An Oranisational Perspective on Collaborative Business Processes By one messae description md matches another messae description md 2 in Alorithm 2, we mean that they have the same messae, and one has passin direction in while the other has out. With the set L of enerated messain links, we can now finally assemble relative workflow processes. As shown in Fiure 5: (a) is the relative workflow process perceivable from the retailer; and (b) is the relative workflow process perceivable from the manufacturer, where the dashed connectin arrows denote the enerated messae links. Different participatin oranisations may have different views to the same inter-oranisational workflow process. This reflects our relativity characteristics. 5. Trackin on Business Collaborations Once a relative workflow process is enerated at the process level, we may perform workflow trackin of its instances, throuh complex interactions between business process instances of participatin oranisations. Trackin on business collaboration means the ability to track and report on the events happened to a specific business collaborative process durin its execution. In our context, we are referrin to the status enquiries on a relative workflow instance and other related relative workflow instances. As we can see from the relative workflow assemblin alorithm, i.e. Alorithm 2, a relative workflow process is created for a specific oranisation. However, as a relative workflow process is a part of a collaborative workflow process, this oranisation may track the status, for instance, of an outsourced job, and the tasks related to this job. Sometimes, these related tasks may belon to non-neihbourin oranisations. Referrin to the motivatin example in Fiure, the task of the manufacturer s Production process cannot send the confirmation of delivery to the retailer s Product Orderin process until it receives the confirmation of delivery from the shipper s Shippin process. But from the retailer s relative workflow process about the product purchase/supply collaboration shown in Fiure 5 (a), the retailer cannot see this dependency between the manufacturer and the shipper directly. Then, what if the shipper permits the retailer s trackin on its Shippin process? Can the relative workflow model support trackin beyond neihbourin oranisations? We address this issue in this section. As mentioned in Section 3, the trackable visibility value is dedicated to represent the trackability of a task to a specific oranisation. Based on the motivatin example, the shipper may permit the retailer s trackin by sinin a contract, from which the correspondin perception can be defined with some tasks set to trackable for the retailer. For example, here we suppose the shipper defines the followin visibility Shipper. Shippin constraints for the retailer in the perception p, VC 3 = {( s, Trackable), ( Book, Invisible), ( Van, Invisible), (, Trackable) };

12 2 Xiaohui Zhao, Chenfei Liu, and Yun Yan Shipper (Shippin) (Production) Shipper (Shippin) Book Van Order Parts Production Check Inventory Make Goods Dispatch Goods Book ( a ) ( b ) Fi. 6. Shippin process perceivable from different oranisations With such visibility constraints, the retailer can obtain the perceivable Shippin workflow process, which is shown in Fiure 6 (a). Given the visibility constraints defined by the shipper for the manufacturer in the Shipper. Shippin perception p, VC 4 = {( s, Contactable), ( Book, Trackable), ( Van, Invisible), (, Contactable)}, the manufacturer can obtain a relative workflow process about the product delivery collaboration, as shown in Fiure 6 (b). Now, the manufacturer s Production process may become a bride between the retailer and the shipper because it exists in both the retailer s relative workflow process from the manufacturer in Fiure 5 (a) and the manufacturer s relative workflow process from the shipper in Fiure 6 (b). As the Shippin process is also perceivable from the retailer, it is possible for the retailer to track the related tasks in the shipper s Shippin process via the manufacturer. However, such a bridin procedure requires a composite view from the retailer to the shipper by composin the view of the retailer from the manufacturer and the view of the manufacturer from the shipper. This step has to be handled by the manufacturer, since only the manufacturer has the knowlede of all necessary visibility constraints and relative workflow processes. First, we start from the manufacturer s relative workflow process in Fiure 6 (b). We can see that the Collect Order task of the Shippin process has the messae link with the task of the manufacturer s Production process. And the task is also set trackable to the retailer (refer to VC 2 defined in Example ). Therefore, the messae link can be kept as oriinal, because the tasks connected by it are perceivable to both the manufacturer and the retailer. Similarly, the same result can be achieved when composin the messae link. Finally, at the site of the retailer, the trackin structure can be extended by connectin the perceivable Shippin workflow process to its oriinal

13 An Oranisational Perspective on Collaborative Business Processes 3 relative workflow process in Fiure 5 (a), with the composed messae links. The extended trackin structure is iven in Fiure 7. ( Product Orderin ) Raise Order Shipper ( Production ) ( Shippin ) Place Order with Customer Pay Send Order Make Goods Production Approve Payment Dispatch Goods Print Cheque Fi. 7. Trackin structure Once such a trackin structure is derived, the execution information of all involved workflow processes can be collected by propaatin alon this structure. 6 Discussions With the proposed relative workflows, oranisation centred business collaboration can be easily achieved. In this collaboration scheme, an individual oranisation can actively choose partner oranisations, and assemble proper off-the-shelf perceivable workflow processes from partner oranisations with its own workflow processes into a relative workflow process. This relative workflow process forms part of a collaborative workflow process for specific business collaboration. This collaboration scheme has the followin appealin features:. Support of hih autonomy in collaborations. As an autonomous entity, each oranisation is in chare of definin the collaboration structure and behaviours with its partner oranisations to fulfil its own business plannin and manaement, without bein forced to adapt the restrictions and irrationalities caused by the desin of a third party desiner or a leadin oranisation anymore. Therefore, each oranisation owns the full control of its business collaboration. 2. Support of flexible collaborations. The proposed collaboration scheme can support business collaborations amon loosely-coupled oranisations in a dynamic or temporary manner. With the help of this scheme, a participatin oranisation is now able to easily redefine its collaboration structure and behaviours on the fly, e.., to chane partner oranisations, to alter requirements for business collaboration with partner oranisations, etc.

14 4 Xiaohui Zhao, Chenfei Liu, and Yun Yan 3. Support of information protection. The visibility control mechanism prevents the private information disclosure at the task level or at the process level. Participatin oranisations are now able to control the level of information revealin to different participatin oranisations accordinly. As we can see, a collaborative workflow process modelled in the public view approaches can be modelled in our relative workflow approach by a series of relative workflow processes with more advantaes described above. Moreover, it may also support some applications that the public view approaches cannot cope with. One such an application is to support transient supply chains. In current e-marketplaces or other information portals, buyer, supplier, seller and distributor oranisations can exchane their tradin information and find tradin partners. These sorts of collaborations are most likely to be dynamic and temporary, because a partner relationship is usually decided by means of price matchin, biddin or auctions, and it will terminate as soon as the tradin finishes. As discussed earlier, our relative workflow approach can support it very well. Another application is a virtual oranisation alliance consistin of small-to-medium sized enterprises (SMEs), where SMEs join a virtual community to share business services from each other. Each oranisation in such an open alliance is aware of the services utilisable, and also needs to publish its business services to other oranisations. Such a dual-awareness requirement can be well supported usin visibility control based perceptions. In addition, the bottom-up buildin mechanism of relative workflows suits this kind of alliances perfectly. 7 Related Work Chiu et al. [] borrowed the notion of view from federated database systems, and employed a virtual workflow view for the inter-oranisational collaboration instead of the real instance, to hide internal information. Our relative workflows approach extracts the explicit visibility constraints from the commercial contracts to restrict the information disclosure. Different from the workflow view model, the relative workflow approach distributes the macro business collaboration into interactions between neihbourin oranisations, and these interactions are performed by the relative workflows desined from the perspective of individual oranisations. van der Aalst and Weske [4] proposed a top-down approach for interoranisational workflow processes and adopted a public-to-private method to formalise the partition process. In this paper, we take a bottom-up approach to build up relative workflow processes from each individual oranisation first, then to represent a collaborative business process as a series of relative workflow processes. Schulz and Orlowska [3] developed a cross-oranisational workflow architecture, on the basis of communication between the entities of a view-based workflow model. In comparison, our relative workflow approach defines perceptions from the view of each participatin oranisation. The relative workflow processes can be dynamically enerated by linkin the local workflow processes usin perceptions.

15 An Oranisational Perspective on Collaborative Business Processes 5 The CrossFlow project [2] aimed to support cross-oranisational workflow manaement in a dynamic virtual enterprise, with the cooperation based on dynamic service outsourcin specified in electronic contracts. However, the contracts in this project did not include explicit visibility parameters. Compared with this work, our relative workflow approach provides a more systematic support in visibility control. A business contract specification lanuae (XLBC) was introduced in [] to formally link the Component Definition Lanuae (CDL) specification of business object based workflow systems. A brief discussion on object visibility specified by contracts was also iven in that research. Nevertheless, no more detailed work in that reard could be found. Our relative workflows use perceptions to define a specific visibility of each workflow process to different oranisations. Based on this visibility control mechanism, support of some advanced features, such as flexible collaborations, autonomy in collaborations, are now available. 8 Conclusions This paper has presented a new approach on inter-oranisational business collaboration, by proposin a novel concept called relative workflow. In this approach, each oranisation acts as an autonomous entity with the full control of choosin its partner oranisations and definin its collaboration structure and behaviours. Instead of definin a collaborative business process as a whole, each participatin oranisation may define its relative workflow processes from its own perspective for business collaboration. Associated with a relative workflow process, a set of visibility constraints are defined for interaction and trackin. In this paper, both the formal definitions of relative workflows and the alorithms for eneratin relative workflows have been presented. The trackin on relative workflow processes has also been discussed. In the future, we plan to prototype this work in the Web service environment and to refine the relative workflow architecture to better support collaborative business processes. Acknowledements The work reported in this paper is partly supported by the Australian Research Council discovery project DP References. Osterle, H., Fleisch, E.Alt, R.: Business Networkin - Shapin Collaboration between Enterprises. Spriner Verla (2) 2. Grefen, P., Aberer, K., Ludwi, H.Hoffner, Y.: CrossFlow: Cross-Oranizational Workflow Manaement for Service Outsourcin in Dynamic Virtual Enterprises. Data Enineerin, 24() (2) 52-57

16 6 Xiaohui Zhao, Chenfei Liu, and Yun Yan 3. Schulz, K. and Orlowska, M.: Facilitatin Cross-oranisational Workflows with a Workflow View Approach. Data & Knowlede Enineerin, 5() (24) van der Aalst, W. and Mathias, W.: The P2P Approach to Inter-oranizational Workflows. Advanced Information Systems Enineerin, Proceedins (2) Wetzel, I. and Klischewski, R.: Serviceflow beyond Workflow? IT Support for Manain Inter-oranizational Service Processes. Information Systems, 29(2) (24) Groiss, H. and Eder, J.: Workflow Systems for Inter-oranizational Business Processes. SIGGroup Bulletin, 8(3) (997) Business Process Execution Lanuae for Web Services (BPEL4WS) Ver.. (23) 8. Zhao, X., Liu, C.Yan, Y.: Web Service based Architecture for Workflow Manaement Systems. Database and Expert Systems Applications, Proceedins, LNCS 38 (24) Anderson, M. and Allen, R.: Workflow Interoperability - Enablin E-Commerce. (999). Chiu, D., Cheun, S., Karlapalem, K., et al.: Workflow View Driven Cross-oranizational Interoperability in a Web-service Environment. Web Services, E-Business, and the Semantic Web, LNCS 252 (22) van den Heuvel, W. and Weiand, H.: Cross-Oranizational Workflow Interation usin Contracts. ACM Conference on Object-Oriented Prorammin, Systems, Lanuaes, and Applications (2)