An Organisational Perspective on Collaborative Business Processes

An Organisational Perspective on Collaborative Business Processes Xiaohui Zhao, Chengfei Liu, and Yun Yang CICEC - Centre for Internet Computing and E-Commerce, Faculty of Information and Communication Technologies, Swinburne University of Technology, Melbourne, VIC 3122, Australia {xzhao, cliu, yyang}@it.swin.edu.au

Abstract. Business collaboration is about coordinating the flow of information among organisations and linking their business processes. It brings great challenge to keep participating organisations as autonomous entities in integrating business processes of these organisations seamlessly. To address this issue, we develop a new perspective on business collaborations with a novel concept called relative workflow, which defines what a participating organisation can perceive in collaboration. By incorporating a visibility control mechanism, relative workflows allow each organisation to define its own collaboration structure and behaviours. In this paper, we present a formal definition of relative workflows and related algorithms for generating relative workflows, along with a discussion on how to perform tracking over relative workflows.

1 Introduction Recent years have seen the trend of global business collaboration urgently requiring organisations to dynamically form virtual organisation alliances. The business processes of different organisations need to be integrated seamlessly to adapt the continuously changing business conditions and to stay competitive in the global market [1]. To enable such business collaboration, research efforts have been put on improving current workflow technologies for supporting collaborative business processes [2-6]. Web service technology has also emerged partly for this purpose and has been deployed for implementing inter-organisational workflows [7,8]. Current inter-organisational workflow approaches mainly focus on modelling workflows from a public view, where a third-party designer or the leading organisation of a virtual organisation alliance defines the business collaboration structure and behaviours by choosing participating organisations and linking workflow processes of these organisations into an inter-organisational workflow process. These approaches work well with the assumption that there exists a thirdparty designer or a leading organisation that can see certain level of details of all participating organisations. However, this assumption is too restrictive. Though several organisations may be involved in the same collaborative business process for a defined business goal, the relationship between each pair of participating organisations could be different. As such, the visibility between participating W.M.P. van der Aalst et al. (Eds.): BPM 2005, LNCS 3649, pp. 17 – 31, 2005. © Springer-Verlag Berlin Heidelberg 2005

18

X. Zhao, C. Liu, and Y. Yang

organisations may be relative, rather than absolute as adopted in the public view approaches. Besides, the predominant view of a third-party designer or a leading organisation may put participating organisations in a passive position. This violates that each participating organisation 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. Aiming at solving these problems, we develop a new perspective on business collaboration based on a novel concept called relative workflow, to support participating organisations 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 participating organisation. This allows each organisation, as an autonomous entity, to design its own collaboration structure and behaviours. The third party or leading-organisation-oriented inter-organisational workflow design can be distributed into multiple one-party oriented relative workflow process design. Different visibility constraints can then be defined for different organisations to reflect the fine granularity of visibility control between participating organisations. The remainder of this paper is organised as follows. In Section 2, we analyse, with a motivating 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 algorithms for generating relative workflow processes. Section 5 addresses how to perform workflow tracking among organisations. Section 6 discusses the advantages of relative workflows and their applied domains. Related work and concluding remarks are given in Section 7 and Section 8, respectively.

2 Requirement Analysis with Motivating Example Traditional inter-organisational workflow design approaches streamline business processes contributing to a common business goal, yet belonging to different organisations, into a public workflow process. As discussed earlier, this procedure has the following problems. The first problem is that the collaboration choreography of all participating organisations is determined by a third party designer or a leading organisation. Following this approach, each organisation behaves in the collaboration passively as a worker does in a pipeline workshop. We find that in many cases, a participating organisation expects to choose its own partner organisations and define interorganisational workflow processes by itself to adapt its own collaboration objectives and benefits rather than delegate to a third-party designer or a leading organisation. Actually, it is not always possible to find an appropriate third party designer or a leading organisation. The second problem is the coarse granularity of visibility control. As the public inter-organisational workflow process is open to each involved organisation, either excessive information has to be disclosed or required collaboration information is not provided sufficiently. In the former, some private business information may be

An Organisational Perspective on Collaborative Business Processes

19

disclosed unwillingly to an involved organisation with a distant partner relationship. In the latter, business processes belonging to involved organisations cannot be integrated seamlessly. The third problem may be caused by pre-determined collaboration choreography of participating organisations. This may not be applicable to some business collaboration scenarios, where the partner relationship between participating organisations may be changed in an ad hoc manner. We believe that business collaboration should be decided from the view of each individual organisation, i.e., an organisation defines its collaboration structure and behaviours by following corresponding contracts with proper partner organisations, and may change them later by updating existing contracts or signing new contracts. In this way, each organisation acts as a highly autonomous collaboration participant. Retailer (Product Ordering) Raise Order

Manufacturer

Shipper

Supplier

(Production)

(Shipping)

(Supplying)

Schedule Delivery

Collect Order

Collect Order Order Parts

Place Order with Manufacturer

Schedule Production

Invoice Customer

Confirm Delivery

Schedule Van

Check Inventory Pay Invoice Approve Payment

Make Goods

Confirm Delivery Stock Parts

Dispatch Goods Print Cheque

Book Delivery

Collect Order

Preparation

Delivery

Invoice Manufacturer

Check Arrival DB

Invoice Retailer

Pay Supplier (Inventory Management)

Fig. 1. Inter-organisational workflow process example (modified from [9])

Figure 1 shows business collaboration among a retailer, a manufacturer, a shipper and a supplier, from a public view. Five intra-organisational workflow processes and their interaction are shown in the figure. When a ‘Product Ordering’ 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 enough orders from more than one ‘Product Ordering’ process for the purpose of batch production. Before it starts producing products, the manufacturer needs to order necessary parts from suppliers, which will interact with the ‘Inventory Management’ process of the manufacturer later for arrival checking and invoice/payment processing. Also, the manufacturer needs to contact shippers to book the delivery of products, and simultaneously checks inventory with the ‘Inventory Management’ process through the corporate database within the same organisation. Finally, the retailer receives the products from the shipper, and pays the invoice to the manufacturer. In this example, all the participating organisations have the global knowledge of the whole collaboration process, which is somehow pre-determined and may be

20


defined by a third party designer or a leading organisation such as the manufacturer. Once the collaborative process has been defined, each participating organisation acts passively and loses more or less its autonomy. It will be difficult for an organisation to change its collaboration structure and behaviours, for instance, to start a new partner relationship or to terminate an existing partner relationship. Besides, the global knowledge of the whole collaboration process gives no chance to define a close or distant partner relationship between participating organisations. For example, from Figure 1, 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 participating organisations, 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 knowledge about a shipper of the manufacturer so that tracking on the delivery of products may be made possible. We may also need to allow that a manufacturer changes 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 participating organisations as autonomous entities. The different views from individual organisations are well supported by the concept of relative workflows. This approach also provides visibility control with the finer granularity and allows the easy change 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-organisational workflow processes of participating organisations and their interaction. We call these intraorganisational workflow processes as local workflow processes. Definition 1 (Local Workflow Process). A local workflow process lp is defined as a directed acyclic graph ( T, R ), where T is the set of nodes representing the set of tasks, and R⊆T×T is the set of arcs representing the execution sequence. Definition 2 (Organisation). An organisation g is defined as a set of local workflow processes {lp1, lp2, … , lpn}. An individual local workflow process lpi of g is denoted as g.lpi. As the owner of local workflow processes, a participating organisation may wish to protect the critical or private business information of some workflow tasks from disclosing to other participating organisations, during business collaboration. According to the two most important behaviours in the context of collaborative workflows, i.e. workflow tracking and business interaction, we define the following three values for the visibility of workflow tasks as listed in Table 1.


21

Table 1. Visibility values Visibility value Invisible Trackable Contactable

Explanation A task is said invisible to an external organisation, if it is hidden from that organisation. A task is said trackable to an external organisation, if that organisation is allowed to trace the execution status of the task. A task is said contactable to an external organisation, if the task is trackable to that organisation and the task is also allowed to send/receive messages to/from that organisation 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 1. Based on Figure 1, two sets of visibility constraints are given as follows: VC1 = { (‘Raise Order’, Invisible), (‘Place Order with Manufacturer’, Contactable), (‘Invoice Customer’, Contactable), (‘Pay Invoice’, Contactable), (‘Approve Payment’, Invisible}), (‘Print Cheque’, Invisible)}. VC2 = { (‘Collect Order’, Contactable), (‘Order Parts’, Invisible), (‘Schedule Production’, Trackable), (‘Schedule Delivery’, Trackable), (‘Confirm Delivery’, Contactable), (‘Check Inventory’, Invisible), (‘Make Goods’, Trackable), (‘Dispatch Goods’, Trackable), (‘Invoice Retailer’, Contactable)}.

These two sets are defined on the ‘Product Ordering’ and ‘Production’ processes, respectively. Definition 4 (Perception). A perception p gg0 .lp of an organisation g0’s local workflow 1 process lp from another organisation g1 is defined as ( VC, MD, f ), where − VC is a set of visibility constraints defined on g0.lp. − MD ⊆ M × { in, out }, is a set of the message descriptions that contains the messages and the passing directions. M is the set of messages used to represent inter-organisational business activities. − f: MD → g0.lpg1.T is the mapping from MD to g0.lpg1.T, and g0.lpg1 is the perceivable workflow process of g0.lp from g1. The generation of g0.lpg1 from g0.lp will be discussed in the next section. Example 2. Again, based on Figure 1, the perception of the retailer’s ‘Product Ordering’ process from the manufacturer, and the perception of the manufacturer’s ‘Production’ process from the retailer are given, respectively, as follows: retailer. productOrdering = ( VC1, p Manufactur er {(‘Order of Products’, out), (‘Confirmation of Delivery Date’, in), (‘Invoice’, in) }, {(‘Order of Products’, out) → ‘Place Order with Manufacturer’, (‘Confirmation of Delivery Date’, in) → ‘Invoice Customer’, (‘Invoice’, in)→ ‘Pay Invoice’} ); Manufacturer. production = ( VC2, pretailer

{(‘Order of Products’, in), (‘Confirmation of Delivery Date’, out), (‘Invoice’, out) },

22


{(‘Order of Products’, in) → ‘Collect Order’, (‘Confirmation of Delivery Date’, out) → ‘Confirm Delivery’, (‘Invoice’, out) → ‘Invoice Retailer’} ). where VC1 and VC2 are defined in Example 1.

Definition 5 (Relative Workflow Process). A relative workflow process g1.rp perceivable from an organisation g1 is defined as a directed acyclic graph ( T, R ), where T is the set of the tasks perceivable from g1, which is a union of the following two parts: − ∪ g1.lp k .T , the union of the task sets of all g1.lpk. k

−

∪ ∪ g i .lp gj .T i

j

, the union of the task sets of all perceivable workflow processes of

1

gi.lpj from g1. R is the set of arcs perceivable from g1, which is a union of the following three parts: − ∪ g1.lp k .R , the union of the arc sets of all g1.lpk. k

− ∪ ∪ gi .lp j .R , the union of the arc sets of all perceivable workflow processes of g1 i

j

gi.lpj from g1. − L, the set of messaging links between local and perceivable workflow processes, consisting of two parts: − Lintra, the set of intra-organisational messaging links that connect tasks belonging to different local workflow processes, and is defined on U U g1.lp i .T × g1.lp j .T where i ≠ j . i j

− Linter, the set of inter-organisational messaging links that connect tasks between a local workflow process and a perceivable workflow process, and is defined on U U U g1.lp k .T × g i .lp gj .T ∪ g i .lp gj .T × g1.lp k .T . i j k

g0

(

1

g 1 Relative Workflow Process

Relative Workflow Process

1

1

has

1

1

has

[1, n]

Message Link Set

1

1

Preceivable Wf Process

1

1

has

[1, n]

[1, n]

Local Wf Process

1

has

has

[1,n]

)

1

has [1, n]

[1,n]

Preceivable Wf Process

Message Link Set

1

Local Wf Process 1

1

composes

composes [1, n]

[1, n]

Message Description

Visibility Constraints

[1, n]

[1, n]

has

1

Perception

1

has

match

[1, n]

[1, n]

Message Description

Visibility Constraints

[1, n]

has

[1, n] 1

Fig. 2. Relative workflow model

Perception

1

has


23

Figure 2 illustrates how the components of the relative workflow model are related across organisations. Given the discussion and definition of the relative workflow process above, a necessary procedure for an organisation, g0 or g1, to generate relative workflow processes is to define the perceptions on local workflow processes. This step includes defining visibility constraints, message links and matching functions. Once the perceptions on local workflow processes of its partner organisations have been defined, a relative workflow process can be generated by two more steps: composing tasks and assembling relative workflow processes. The purpose of composing tasks is to hide some private tasks of local workflow processes. We choose to merge invisible tasks with the contactable or trackable tasks into composed tasks, if not violating the structural validity; otherwise, those invisible tasks are combined into a dummy task. According to the perception defined from g1, a local workflow process of g0 after this step becomes a perceivable workflow process for g1. In the step of assembling relative workflow processes, an organisation, say g1, assembles its local workflow processes with perceivable workflow processes from its partner organisations, say g0, into a relative workflow process, as shown in Figure 2. The details are to be discussed in the following section.

4 Generating Relative Workflow Processes 4.1 Defining Perceptions A perception can be derived by analysing and decomposing a commercial contract between organisations in connection to certain business collaboration. Unlike a contract, a perception is defined from the perspective of one organisation on the local workflow processes of other participating organisations. To represent a business Retailer ( Product Ordering )

Manufacturer ( Production ) “Order of Products”

Raise Order


Invoice Customer

Order Parts “Order of Products”

“Confirmation of Delivery”

Pay Invoice

Schedule Production Schedule Delivery

“Invoice”


Approve Payment

Collect Order

Check Inventory Make Goods

Confirm Delivery Dispatch Goods

Print Cheque

“Invoice”

Fig. 3. Local workflow processes

Invoice Retailer

24


interaction between an organisation g0 and other participating organisations g1 , … , gm, two sets of such perceptions are required: PS1, the set of the perceptions defined n0

1

1

on g0.lp1, … , g 0 .lp n0 from g1 , … , gm, i.e. { p gg 0 .lp , … , p gg 0 .lp , … , p gg 0 .lp , … , 1 m 1 n0

p gg 0 .lp }; and PS2, the set of the perceptions defined on all local workflow processes m

n1

1

1

of g1 , … , gm from g0, i.e. { p gg1 .lp , … , p gg1 .lp , … , p gg m .lp , … , p gg m .lp 0

0

0

0

nm

}.

Figure 3 shows the ‘Product Ordering’ process and the ‘Production’ process in Figure 1, where the dashed arrows denote the message descriptions. To represent the business interaction between these two processes, we can define the perception Retailer.productOrdering of the retailer’s ‘Product Ordering’ process from the manufacturer p Manufactur er Manufacturer . production and the perception p Retaile of the manufacturer’s ‘Production’ process from r the retailer, which are already given in Example 1.

4.2 Composing Tasks

In this step, a local workflow process needs to hide its invisible tasks by composing them with proper contactable or trackable tasks for creating the corresponding perceivable workflow process. The algorithm is given below. For the simplicity of discussion, we only consider composing one local workflow process lp of the organisation g0 from another organisation g1. Furthermore, we conduct a pre-processing on all split/join structures of lp such that for all those branches consisting of only invisible tasks, a dummy task is created to delegate these branches. Algorithm 1. Task Composition

Input:

lp = g0.lp, the organisation g0’s local workflow process lp before composition p = p g 0 .lp , the perception of g0’s lp from g1 g1

Output: lp′ = g0.lpg1, the perceivable workflow process composed from lp for g1, according to p g 0 .lp . g1

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)=(indegree(t)=1∧outdegree(t)=1) { 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 incoming interaction tasks while ((∃t∈VT (p′.f -1(t)=(m, in)∧outdegree(t) =1)∧(∃t′∈(lp′.T-VT))((t, t′)∈lp′.R∧indegree(t′)=1)) { 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° ; }


25

// upward composition with outgoing interaction tasks while ((∃t∈VT (p′.f -1(t)=(m, out)∧indegree(t) =1)∧(∃t′∈(lp′.T-VT))((t′,t)∈lp′.R∧outdegree(t′)=1)) { 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° ; }

Algorithm 1 first keeps composing each pair of neighbouring sequential invisible tasks into one invisible task, then downward composes invisible tasks with incoming interaction tasks and upward composes invisible task with outgoing interaction tasks. Figure 4 shows the results of task composition: (a) is the perceivable ‘Product Ordering’ process of the retailer from the manufacturer; and (b) is the perceivable ‘Production’ process of the manufacturer from the retailer, where the dashed rectangles denote invisible tasks. Retailer

Manufacturer ( Production )

( Product Ordering ) “Order of Products”

Raise Order



Invoice Customer

“Order of Products”


Pay Invoice

Schedule Delivery

Check Inventory

“Invoice”


Approve Payment

Schedule Production

Confirm Delivery

Make Goods Dispatch Goods

Print Cheque

“Invoice”

(a)

Invoice Retailer (b)

Fig. 4. Perceivable workflow processes

4.3 Assembling Relative Workflow Processes

In this step, proper local workflow processes and perceivable workflow processes are connected together by linking the corresponding interaction operations. This can be achieved by matching the message descriptions defined in the perceptions, using the algorithm below. Similarly, for the simplicity of discussion, we only consider matching one local workflow process lp of the organisation g0 from another organisation g1.

26

X. Zhao, C. Liu, and Y. Yang Algorithm 2. Local Workflow Process Matching Input: lp' = g0.lpg1, the perceivable workflow process composed from g0’s local workflow process lp. g .lp

p = pg 0 1

, the perception of g0’s lp from g1 g .lp 1n1

g .lp 1

ps = { p g 1 , … , pg1 }, the set of perceptions defined on g1’s perceivable workflow 0 0 processes from g0 Output: L, the set of generated messaging links L = ∅; for each t ∈lp′.T if ∃md( p.f-(md)= t) then { md1=p.f -1(t); for each p°∈ps for each md2∈p°.MD if md1 matches md2 then L = L ∪{(t, p°.f(md2), md1)}; }


Retailer ( Product Ordering )


Retailer ( Product Ordering )

Collect Order

Raise Order



Send Order

Confirm Delivery

Approve Payment

Send Order

Schedule Production


Schedule Delivery

Invoice Customer

Pay Invoice

Schedule Production

Make Goods Confirm Delivery

Invoice

Dispatch Goods

Invoice Customer

Confirm Delivery

Check Inventory

Confirm Delivery

Make Goods

Pay Invoice Invoice

Invoice Retailer

Print Cheque

Schedule Delivery

(a)

Dispatch Goods Invoice Retailer (b)

Fig. 5. Relative workflow processes

By one message description md1 matches another message description md2 in Algorithm 2, we mean that they have the same message, and one has passing direction ‘in’ while the other has ‘out’. With the set L of generated messaging links, we can now finally assemble relative workflow processes. As shown in Figure 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 connecting arrows denote the generated message links. Different participating organisations may have different views to the same inter-organisational workflow process. This reflects our relativity characteristics.


27

5 Tracking on Business Collaborations Once a relative workflow process is generated at the process level, we may perform workflow tracking of its instances, through complex interactions between business process instances of participating organisations. Tracking on business collaboration means the ability to track and report on the events happened to a specific business collaborative process during its execution. In our context, we are referring to the status enquiries on a relative workflow instance and other related relative workflow instances. As we can see from the relative workflow assembling algorithm, i.e. Algorithm 2, a relative workflow process is created for a specific organisation. However, as a relative workflow process is a part of a collaborative workflow process, this organisation may track the status, for instance, of an outsourced job, and the tasks related to this job. Sometimes, these related tasks may belong to non-neighbouring organisations. Referring to the motivating example in Figure 1, the ‘Confirm Delivery’ task of the manufacturer’s ‘Production’ process cannot send the confirmation of delivery to the retailer’s ‘Product Ordering’ process until it receives the confirmation of delivery from the shipper’s ‘Shipping’ process. But from the retailer’s relative workflow process about the product purchase/supply collaboration shown in Figure 5 (a), the retailer cannot see this dependency between the manufacturer and the shipper directly. Then, what if the shipper permits the retailer’s tracking on its ‘Shipping’ process? Can the relative workflow model support tracking beyond neighbouring organisations? 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 organisation. Based on the motivating example, the shipper may permit the retailer’s tracking by signing a contract, from which the corresponding perception can be defined with some tasks set to ‘trackable’ for the retailer. For example, here we suppose the shipper defines the following visibility Shipper .Shipping constraints for the retailer in the perception p Retailer , VC3 = {(‘Collect Orders’, Trackable), (‘Book Delivery’, Invisible), (‘Schedule Van’, Invisible), (‘Confirm Delivery’, Trackable) };

With such visibility constraints, the retailer can obtain the perceivable ‘Shipping’ workflow process, which is shown in Figure 6 (a). Given the visibility constraints defined by the shipper for the manufacturer in the Shipper .Shipping perception pManufactur , er VC4 = {(‘Collect Orders’, Contactable), (‘Book Delivery’, Trackable), (‘Schedule Van’, Invisible), (‘Confirm Delivery’, Contactable)},

the manufacturer can obtain a relative workflow process about the product delivery collaboration, as shown in Figure 6 (b). Now, the manufacturer’s ‘Production’ process may become a bridge between the retailer and the shipper because it exists in both the retailer’s relative workflow process from the manufacturer in Figure 5 (a) and the manufacturer’s relative workflow process from the shipper in Figure 6 (b). As the ‘Shipping’ process is also perceivable from the retailer, it is possible for the retailer to track the related tasks in the shipper’s ‘Shipping’ process via the manufacturer.

28

X. Zhao, C. Liu, and Y. Yang Shipper

Manufacturer

Shipper

(Shipping)

(Production)

(Shipping)

Collect Order

Collect Order

Schedule Delivery

Order Parts Collect Order

Book Delivery

Schedule Production

Schedule Delivery

Check Inventory

Confirm Delivery

Book Delivery

Schedule Van Confirm Delivery

Confirm Delivery

Make Goods

Confirm Delivery

Dispatch Goods Invoice Retailer (a)

(b)

Fig. 6. ‘Shipping’ process perceivable from different organisations

However, such a bridging procedure requires a composite view from the retailer to the shipper by composing 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 knowledge of all necessary visibility constraints and relative workflow processes. First, we start from the manufacturer’s relative workflow process in Figure 6 (b). We can see that the ‘Collect Order’ task of the ‘Shipping’ process has the ‘Schedule Delivery’ message link with the ‘Schedule Delivery’ task of the manufacturer’s ‘Production’ process. And the ‘Schedule Delivery’ task is also set trackable to the retailer (refer to VC2 defined in Example 1). Therefore, the ‘Schedule Delivery’ message link can be kept as original, because the tasks connected by it are perceivable to both the manufacturer and the retailer. Similarly, the same result can be achieved when composing the ‘Confirm Shipper


Retailer ( Product Ordering ) Raise Order

( Shipping )

Collect Order Send Order

Schedule Production


Schedule Delivery

Collect Order Invoice Customer

Make Goods

Confirm Delivery

Pay Invoice Approve Payment

Schedule Delivery

Invoice

Dispatch Goods Invoice Retailer

Print Cheque Confirm Delivery

Fig. 7. Tracking structure

Confirm Delivery

Confirm Delivery


29

Delivery’ message link. Finally, at the site of the retailer, the tracking structure can be extended by connecting the perceivable ‘Shipping’ workflow process to its original relative workflow process in Figure 5 (a), with the composed message links. The extended tracking structure is given in Figure 7. Once such a tracking structure is derived, the execution information of all involved workflow processes can be collected by propagating along this structure.

6 Discussions With the proposed relative workflows, organisation centred business collaboration can be easily achieved. In this collaboration scheme, an individual organisation can actively choose partner organisations, and assemble proper ‘off-the-shelf’ perceivable workflow processes from partner organisations 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 following appealing features: 1.

Support of high autonomy in collaborations. As an autonomous entity, each organisation is in charge of defining the collaboration structure and behaviours with its partner organisations to fulfil its own business planning and management, without being forced to adapt the restrictions and irrationalities caused by the design of a third party designer or a leading organisation anymore. Therefore, each organisation owns the full control of its business collaboration. 2. Support of flexible collaborations. The proposed collaboration scheme can support business collaborations among loosely-coupled organisations in a dynamic or temporary manner. With the help of this scheme, a participating organisation is now able to easily redefine its collaboration structure and behaviours on the fly, e.g., to change partner organisations, to alter requirements for business collaboration with partner organisations, etc. 3. Support of information protection. The visibility control mechanism prevents the private information disclosure at the task level or at the process level. Participating organisations are now able to control the level of information revealing to different participating organisations accordingly.

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 advantages 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 organisations can exchange their trading information and find trading partners. These sorts of collaborations are most likely to be dynamic and temporary, because a partner relationship is usually decided by means of price matching, bidding or auctions, and it will terminate as soon as the trading finishes. As discussed earlier, our relative workflow approach can support it very well. Another application is a virtual

30


organisation alliance consisting of small-to-medium sized enterprises (SMEs), where SMEs join a virtual community to share business services from each other. Each organisation in such an open alliance is aware of the services utilisable, and also needs to publish its business services to other organisations. Such a dual-awareness requirement can be well supported using visibility control based perceptions. In addition, the “bottom-up” building mechanism of relative workflows suits this kind of alliances perfectly.

7 Related Work Chiu et al. [10] borrowed the notion of ‘view’ from federated database systems, and employed a virtual workflow view for the inter-organisational 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 neighbouring organisations, and these interactions are performed by the relative workflows designed from the perspective of individual organisations. van der Aalst and Weske [4] proposed a “top-down” approach for interorganisational 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 organisation first, then to represent a collaborative business process as a series of relative workflow processes. Schulz and Orlowska [3] developed a cross-organisational 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 participating organisation. The relative workflow processes can be dynamically generated by linking the local workflow processes using perceptions. The CrossFlow project [2] aimed to support cross-organisational workflow management in a dynamic virtual enterprise, with the cooperation based on dynamic service outsourcing 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 language (XLBC) was introduced in [11] to formally link the Component Definition Language (CDL) specification of business object based workflow systems. A brief discussion on object visibility specified by contracts was also given in that research. Nevertheless, no more detailed work in that regard could be found. Our relative workflows use perceptions to define a specific visibility of each workflow process to different organisations. 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-organisational business collaboration, by proposing a novel concept called relative workflow. In this


31

approach, each organisation acts as an autonomous entity with the full control of choosing its partner organisations and defining its collaboration structure and behaviours. Instead of defining a collaborative business process as a whole, each participating organisation 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 tracking. In this paper, both the formal definitions of relative workflows and the algorithms for generating relative workflows have been presented. The tracking 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.

Acknowledgements The work reported in this paper is partly supported by the Australian Research Council discovery project DP0557572.

References 1. Osterle, H., Fleisch, E.Alt, R.: Business Networking - Shaping Collaboration between Enterprises. Springer Verlag (2001) 2. Grefen, P., Aberer, K., Ludwig, H.Hoffner, Y.: CrossFlow: Cross-Organizational Workflow Management for Service Outsourcing in Dynamic Virtual Enterprises. Data Engineering, 24(1) (2001) 52-57 3. Schulz, K. and Orlowska, M.: Facilitating Cross-organisational Workflows with a Workflow View Approach. Data & Knowledge Engineering, 51(1) (2004) 109-147 4. van der Aalst, W. and Mathias, W.: The P2P Approach to Inter-organizational Workflows. Advanced Information Systems Engineering, Proceedings (2001) 140-156 5. Wetzel, I. and Klischewski, R.: Serviceflow beyond Workflow? IT Support for Managing Inter-organizational Service Processes. Information Systems, 29(2) (2004) 127-145 6. Groiss, H. and Eder, J.: Workflow Systems for Inter-organizational Business Processes. SIGGroup Bulletin, 18(3) (1997) 23-26 7. Business Process Execution Language for Web Services (BPEL4WS) Ver1.1. http://www.ibm.com/developerworks/library/ws-bpel/ (2003) 8. Zhao, X., Liu, C.Yang, Y.: Web Service based Architecture for Workflow Management Systems. Database and Expert Systems Applications, Proceedings, LNCS 3180 (2004) 3443 9. Anderson, M. and Allen, R.: Workflow Interoperability - Enabling E-Commerce. www.aiim.org/wfmc/mainframe.htm (1999) 10. Chiu, D., Cheung, S., Karlapalem, K., et al.: Workflow View Driven Cross-organizational Interoperability in a Web-service Environment. Web Services, E-Business, and the Semantic Web, LNCS 2512 (2002) 41-56 11. van den Heuvel, W. and Weigand, H.: Cross-Organizational Workflow Integration using Contracts. ACM Conference on Object-Oriented Programming, Systems, Languages, and Applications (2000)