semantically mapped to process concepts and then analyzed for compliance with existing process models. To solve the problem, we propose a methodology.
Enabling Business Process Interoperability Using Contract Workflow Models Jelena Zdravkovic1,2, Vandana Kabilan2 1
Department of Computer Science, University of Gävle Kungsbäcksvägen 47, 80 277 Gävle, Sweden 2 Department of Computer and Systems Sciences Stockholm University and Royal Institute of Technology Forum 100, SE-164 40 Kista, Sweden {jzc, vandana}@dsv.su.se
Abstract. Business transactions are governed by legally established contracts. Contractual obligations are to be fulfilled by executing business processes of the involved parties. To enable this, contract terms and conditions need to be semantically mapped to process concepts and then analyzed for compliance with existing process models. To solve the problem, we propose a methodology that, using a layered contract ontology, deduces contract requirements into a high-level process description named Contract Workflow Model (CWM). By applying a set of transformation rules, the CWM is then compared for compliance with existing, executable process models. By the use of its concepts, the methodology enables comprehensive identification and evolution of requirements for interoperability of processes of the contracting parties.
1
Introduction
The purpose of establishing a business contract is to agree upon the rules and regulations governing interactions between the agreement partners. A contract testifies the legal binding nature of an agreement, as well as the remedial options and rights granted to the partners in case of any disagreement or dispute. Information contained in a contract needs to be assimilated as knowledge, which may be analyzed and reused in the business process management. The contract management domain has existed for some time as well as the business process management. However, most available solutions such as Enterprise Resource Planning (ERP), Customer Relationship Management (CRM) or other database applications for enterprise or contract management, have not managed to integrate the two domains seamlessly. A business contract is like a master plan for expected business behavior of the parties involved. Generally, it covers most contingencies and probable scenarios for planned execution of the commitments the parties make to each other. Thus, non-compliance to the contract terms could lead to legal, economic and busi-
ness repercussions. This means the actual business processes of the parties must follow the rules established by a contract. A successful contract is negotiated such that the terms are beneficial to all the parties involved. The contract stipulates both implied and explicit obligations, which are legal bindings, and need to be fulfilled as agreed. Therefore, a contract once negotiated and signed cannot be forgotten. It needs to be realized by the business process. To ensure interoperability of the partners’ business processes, it is necessary to have ability to examine the compliance between the process models and the respective contract requirements. Existing methodologies fail to bridge the chasm in between the two domains. In this work, we first present a detailed conceptual model for modeling contract knowledge in a structured and layered form, named Multi Tier Contract Ontology. Secondly, we analyze different types of contract obligations and we identify the states through which each obligation passes through. Thirdly, based on the contract ontology and obligation state classification, we deduce a high-level process model named Contract Workflow Model (CWM). Lastly, by utilizing a structured process design framework, we set up a comprehensive set of rules for examining the compliance between CWM and existing executable business processes (or simply, business processes). The use of the rules enables continuous traceability of alignment between the contract obligations represented by a CWM, and a business process. The paper is structured as follows. Section 2 gives an overview of related research. In Section 3 we first summarize our previous work on the Multi Tier Ontology; using a case study based on the INCOTERMS delivery patterns, we then introduce the methodology for deducing the Contract Workflow Model from the MTCO. In Section 4, by applying a comprehensive process design framework, we define the compliance rules between the CWM and the business process. Finally, Section 5 concludes the paper and gives suggestions for further research.
2
Related Research
Modeling of business contracts has been widely studied in the research community [1], [2], [3], [4], [5]. We have considered and enhanced those approaches when defining our contract ontology (MTCO, [6]). We have modeled obligation states to capture the information relevant to that obligation, as the fulfillment is being executed. Relationship between obligations, obligation states and performance events forms the foundation for the proposed CWM methodology. Our identification of the different obligation states is based on Yao-Hua Tan’s work in [4]. The SweetDeal project [7] is closest to our MTCO and CWM in that they try to capture the semantics of different contract scenarios. Many efforts have been made toward realization of electronic contracts using processes [5], [8], [9], [10]. Our methodology differs in two ways. First, in contract modeling, we focus on grasping the necessary semantic content irrespective of technology used. Second, in contract realization, we aim for integrating contract models with existing business processes rather then creating new process models. In that context our works is closest to van der Aalst’s concept of workflow inheritance [11] used to
compare public and private processes. In contrast to that work, our contract process model (CWM) comprises both public and private behavior; in addition, we compare the CWM with existing (private) processes using a less-formal method than van der Aalst, but more comprehensive.
3
Deducing the Contract Workflow Model (CWM) using the Multi-Tier Contract Ontology (MTCO)
In this section we first summarize our previous work on the contract knowledge modeling, in the form of a contract ontology named MTCO. Then we describe INCOTERMS delivery patterns, which are later used in our Sale of Goods case study for analyzing buyer’s and seller’s obligations. Based on the concepts of the MTCO, we define the Contract Workflow Model for the INCOTERMS-based case study. 3.1
MTCO
We follow Daskalopulu et al [1] in their identification of the roles of the contractual provisions. They prescribe certain behavior for the parties, under a set of conditions, and for a certain period of time. Thereby, contracts specify procedures that need to be followed. For example, the delivery terms inform the buyer regarding the time limit by which he has to inform the seller regarding his transporter, or any change in venue for the delivery, or delivery date etc. We also follow [2] in their analysis of contracts from various perspectives such as: A contract is an organized collection of concepts, obligations, permissions, entitlements, etc. A contract has also been viewed as a collection of protocols that specify its operational aspects (how the business exchange is to be carried out in reality) or simply parameters (the parties, product, price, delivery quantity, delivery date). The MTCO is a combination of the above aspects as has been presented in [6]. A brief summary is presented below: The Upper Level Core Contract Ontology represents a general composition of a contract, which may be applicable across most of the prevalent types of contracts. The concepts defined here may be considered to be atomic blocks based on which all other contract types may be defined. Fundamental concepts like role, consideration, and obligation are defined here. The second layer is Specific Domain Level Contract Ontology or contract type specific collection of several contract type ontologies. Each ontology represents a specific contract type, such as Property Lease Rental, Employment Contract, Sale of Goods, etc. Each contract type inherits all fundamental features of the upper layer and thus specializes on the knowledge particular to that contract domain. The third layer, Template Level Contract Ontology consists of a collection of templates such as definitions for contract models, such as the International Chamber of Commerce’s contract model for International Sale of Goods [12]. In our approach, we model the life-cycle of the contractual obligations as they pass through a set of states in response to identified performance events. For instance, an
obligation, such as the seller’s primary obligation to deliver, is inactive when the contract is signed. It becomes active when the buyer sends a purchase order and the seller accepts the order. Thereafter, the obligation becomes fulfillment triggered when the seller packs and starts the delivery process. Once the buyer accepts and sends notification of acceptance to the seller, the seller’s obligation to deliver may become fulfilled. On the chance that the delivery is rejected and compensation is sought by the buyer, then the seller’s primary obligation is pending while the reconciliatory obligation is now active. In case the buyer cancels the order then the seller’s obligation to deliver becomes cancelled. This proposed classification of obligation states, is the key concept for creating process-based contract choreography in the form of the Contract Workflow Model. In the next section we discuss the INCOTERMS delivery patterns, which are later used in our Sale of Goods case study for analyzing the obligations and the expected business behavior from the seller and the buyer respectively.
3.2
Case Study Scenario: INCOTERMS delivery patterns
Sale of Goods business contracts form the domain of interest for our knowledge models. Such legal contracts, pertaining to purchase and sale, cover a wide arena. We chose a smaller domain of interest as a case study, to model our research goals on. We chose to analyze and model the contractual knowledge from a recommended standard of contract patterns ICC’s INCOTERMS [13]. INCOTERMS provide a set of international rules for the interpretation of the most commonly used trade terms in foreign trade. INCOTERMS form only a part of the vast contractual knowledge contained in a Sale of Goods contract, as recommended by ICC International Sale of Commercial Goods. These are delivery terms agreed between the two parties involved in a sale of goods business transaction. They are internationally accepted as standardized patterns for delivery terms. In this paper, we propose the use of INCOTERMS as a horizontal extension or an individual reusable ontology in the specific domain level of the MTCO. Either the “delivery terms” of a Sale of Goods contract may refer to one of the INCOTERMS standard codes, or the contracting parties may define their own, as the established business practices. The main INCOTERMS concepts are summarized below: Actor. Two or more parties who participate in the purchase and sale of goods. Obligation. An obligation is a promise or commitment made by one party to the other, which is backed up by legal intent to fulfill and uphold the promise. Role. The part an actor plays in the specific contract (i.e. seller, buyer, etc.). Goods. Goods are legally defined as commodities or items of all types, expecting services, which are involved in trade or commerce. Goods are characterized by a description, technical specification, type of packaging required, type of cargo etc. Performance. Every obligation is expected to be fulfilled through the execution of some business, economic or legal action. This expected business behavior is termed as performance.
Delivery Terms. Delivery terms are agreed terms and conditions, which govern the actual process of delivery of goods between the seller and the buyer. Packaging. In most cases the parties know beforehand which type of packaging is required for the safe carriage of the goods to the destination. As the seller's obligation to pack the goods may vary depending upon the type and duration of the transport, it has been stipulated that the seller is obliged to pack the goods in the way it is required for the transport. Inspection of Goods. In many cases the buyer may be advised to arrange for the inspection of goods before, or at the time the goods are handed over by the seller. Payment Terms In relation with delivery terms, Sale of Goods includes payment terms, which are expected in exchange for the goods delivered. Though the INCOTERMS does not go into specific details for the payment terms, the obligation and the performances are outlined. In order to specify the obligations, roles and responsibilities of different delivery protocols, the INCOTERMS have been grouped in four different categories. In our study we will use the term Ex Works, whereby the seller makes the goods available to the Buyer at the seller's own premises, to bring the goods to the country of destination. In Table 1 below, we present a summary Ex Works, in order to elucidate the nature and type of obligations that are present in any such delivery term. In the next section, we base a sample contract example (provided in Annexure A) on the Ex Works obligations from Table 1, and thereafter, we deduce a process-based contract choreography in the form of the Contract Workflow Model. Table 1. Extract of distribution of obligations in Ex Works delivery terms. Obligation
Seller
Provision of goods Yes and Comm. Invoice
Buyer No
Delivery
Place the goods at the named place of deliv- Take delivery as soon ery on the date or within the period stipu- as they have been placed at his disposal. lated.
Payment of price
None
Notice to the buyer
Give notice as to when and where the goods Not applicable shall be placed at the buyer’s disposal.
Packaging, marking
Provide at his own cost packaging as it is required by the circumstances relating to the mode of transport, destination etc. Packaging is to be appropriately marked.
Providing the transport modalities and informing the seller of the required packaging.
Inspection of goods
None
Pay the shipment inspection and inspection mandated by the country of exportation.
Pay the price as provided in the contract.
3.3
Contract Workflow Model for the INCOTERMS Case Study
As we have explained in Section 3.1, the Multi Tier Contract Ontology defines the states the contract obligations may pass, and based on them, a set of performance events that initiate transitions of those states. The expected flow of the performance events (i.e. business actions [14]) is then modeled as a Contract Workflow Model. In [15] we have defined the CWM as: A partial choreography of performance events for each of the parties concerned as deduced from the perspective of the governing business contract and is an indicative model for the contract compliant business process model. Following this, below we outline the procedure for obtaining a CWM from a contract: - The contract document is analyzed to extract the data contained in it. - The extracted data are compared and matched to the specified meta-data concepts as established in the Multi Tier Contract Ontology. The two steps are repeated iteratively to obtain all the concepts and their instances in the contract. - From the identified contract type ontology (in this study – INCOTERMS), the common obligations and their performances, defined or suggested, are considered. Added to the specific information from the contract instance, the list of all stipulated obligations and the required or inferred performance events is obtained. By applying the outlined procedure to our Sale of Goods contract instance (provided in Annexure A), which is based on the Ex Works/INCOTERMS, we sort out the list of the contract obligations and associated performance events (Table 2): Table 2. Partial list of obligations and deduced performance events from the contract sample. Obligation
Possible list of Performance Events
Obligation to deliver
Deliver goods (implied from Ex Works) Take order (implied from the contract) Arrange carrier (implied from the contract) Deliver at the agreed place for point of destination (implied from Ex Works) Notify buyer on delivery (implied from the contract) Compensate rejected delivery (implied from the contract)
Obligation to package
Pack goods (implied from Ex Works)
Obligation to Pay
Inspect Goods (implied from Ex Works)
Mark goods (implied from Ex Works) Notify seller of any discrepancy and demand remedy (implied from the contract) Pay for goods (implied from Ex Works)
The identified obligations and the performance events are further grouped according to the actor performing them. In our case study, the information on responsibilities for
the obligations is identified from the list of distribution of obligations in Ex Works delivery terms (Table 1) and the contract example (Annexure A). As we explained in the previous section, the contractual obligations pass through a set of states in response to the identified performance events. Following this, the performance events from Table 2 are ordered in a time-based sequence according to the life-cycles of the identified obligations. For instance, the seller’s obligation to deliver is changed from the inactive state (when the contract is signed) to the active state when the seller takes (receives) the order from the Buyer; the obligation changes to the fulfillment-triggered state when the goods are to be packed and when the carrier is arranged. By continuing in this way, all identified performance events are ordered in a common, process-based, contract choreography. In order to obtain a “valid” process model, the obtained choreography is then transformed to a Business Process Modeling Notion model [17]. The BPMN is an expressive, graphical process modeling notation, easy understandable by process modelers. In [16], we have defined the core mapping patterns between the concepts of the CWM and the BPMN: - The performance event to the BPMN sub-process, - The obligation states to the BPMN events, - The choreography of performance events to the BPMN sequence flow, - The simultaneous processing of two or more performance events to the BPMN AND gateway, - The exclusive processing of performance events to the BPMN XOR gateway, etc. Following the patterns, we have deduced the CWM for our Sale of Goods example to the BPMN form (Figure 1): OK
B U Y E R
Delivery Accepted
Payment for Invoice
Inspect goods on delivery
Send PO
Goods Delivered
Delivery Rejected
Demand Remedy
Process Response
Cancel Order
Cancellation accepted
Proceed with delivery
Delivery not started cancellation accepted
Cancellation request
Cancellation accepted
Process Cancellation Cancellation rejected
S E L L E R
Delivery started cancellation rejected
Order request
Package Goods
Goods Accepted Notification
Mark Goods Deliver Goods
Post-condition: goods are packed according to the specification
Post-condition: goods are marked according to the specification
Arrange Transport
Compensation
X
10 days, request rejected
Fig. 1. The Contract Workflow Model of the buyer and the seller represented as a BPMN high-level process.
The CWM in Figure 1 is, by the previously described procedure, partitioned on a peractor basis. The performance events from Table 2 are presented as sub-processes, which are triggered by obligation state changes (represented as message-based events in Figure 1). In this way formalized, the CWM forms a high-level business process model, which complies with the agreed contractual terms and conditions. In such way conceptualized, the CWM is used for comparison with existing business processes.
4
Compliance between CWM and Existing Business Processes
In the B2B context, the CWM specifies the agreed contract patterns in the form of a process. As defined the previous section, the CWM represents both the interaction and coordination flow. In terms of interaction, the CWM specifies the protocol for the public message exchange. In terms of coordination, the CWM specifies the flow of business activities. A CWM differs from a business process in the way that it defines the flow of high-level activities. For that reason, the CWM of the seller presented as a BPMN model in Figure 1, may be considered as a partial and high-level specification of seller’s business process. As shown in the previous section, the BPMN technique allows for visualized process modeling. A business process, designed as a BPMN model may be further converted to a BPEL4WS specification [18], using a set of mapping formalisms. In contrast to the language format of a BPEL4WS process specification, a BPMN model enables designer to intuitively and easily capture various aspects of process design. In the following, we define a process design framework to provide a basis for a systematical examination of compliance between a CWM and a business process, both given in the form of BPMN models. By following the framework, we identify compliance rules when mapping CWM to business processes. The total set of rules covers the transformations that may be applied during the assessment of compliance between a CWM and a business process. 4.1
Process Design Framework
In this section we introduce a conceptual framework to classify different aspects that constitute design of a BPMN process. The framework is based on the modelling aspects of workflows, as proposed in [19], [20]. The functional aspect considers the activities of a process. Functionality of each activity is determined by three elements: the activity name which describes the result to be fulfilled, exchanged messages, and input and output constraints, i.e. preconditions and post-conditions. In the BPMN, activities can be non-atomic, such as sub-processes, or atomic, such as tasks. The behavioural aspect depicts the control flow of a process. For specification of dependencies and coordination rules among activities, process models rely on a set of basic control flow constructs: sequence, parallel execution (AND), conditional branching (OR/XOR) and looping. In addition, activities may be triggered by events, which are signalled by internal or external occurrences. In the BPMN semantics, the
normal flow is used to model the basic sequence, while gateways are used to model AND, OR/XOR controls, and loops. Activities might be triggered by three types of events: start, end or intermediate. The BPMN includes the events that affect the sequence or timing of activities of a process. Events are categorized as Start, End, or Intermediate (may be time-, message, cancel-, rule- or error-based). The informational aspect of concerns the information concepts needed for representing process instance data. In a process specification, instance data are represented using internal process attributes upon which flow rules are set and controlled, and with the information that the process exchanges with the external environment in the form of messages (and documents). In the BPMN, the internal data are stored as the properties of a process, message flows indicate information to be exchanged between two entities, while data objects are used to depict documents attached to messages without any information on their content and structure. The organizational aspect concerns the distribution of responsibility for executing activities of a process. This responsibility is assigned to business roles such as seller or buyer. By using roles it is possible to dedicate and control responsibilities of participants engaged in a process. The BPMN uses pools to represent process participants (i.e. business roles). The transactional aspect manages consistent execution of a set of activities. As process activities may have short or long duration, process transactions comply with two different models. The atomic transaction model [21] governs shorter activities, that all agree to enforce a single visible result by two-phase commit. The longrunning transaction model [22] administers more durable activities, where each activity imposes a globally visible outcome independently of the others; when an activity fails, the parent transaction rolls back to a consistent process state by compensating activities that had successfully completed. In the BPMN, a transaction is one mean to ensure the consistent process states by forcing all activities involved to complete or to be cancelled by following one of the two transactional models. Another way is to define custom error-handling that will lead the process to specified consistent states. CWM
Functional
Business Process
Behavioural Informational Organizational Transactional
Fig. 2. The five-aspect framework used for examination of compliance between CWM and business processes.
By following the described framework, in the next section we define rules for compliance between CWM and business processes, for each process design aspect.
4.2
Compliance Rules between CWM and Business Processes
To ensure contract obligations are to be fulfilled in the execution phase, the CWM and the business process need to be compliant. This means that, when enacting a contract, for a business process to be compliant with a CWM, the process must trace the states of the CWM. That ensures that from the CWM view, all obligation states might be monitored. As described in the previous section, five aspects constitute design of a BPMN process; this means that every state in the process comprises the current status of each of the design aspects. To support a CWM, a business process must be thus compliant with the CWM in all five design aspects. Functional Aspect. The CWM models functionality at the level of sub-processes, while the business process does it on the task level. When comparing the CWM with the business process from the functional perspective, we investigate whether activities in the business process are compliant with the CWM activities, with respect to their results, message exchange, and/or imposed pre- and post-conditions. Following this, the functional aspect of a business process will be compliant with a CWM, if the design of the business process satisfies the following rules: Result/Messages. One or more activities in the business process correspond to one activity in the CWM, where the process activities jointly provide the same result and exchange the same messages as the CWM activity. This ensures that the business process can trace the messages and the results of activities in the CWM. Constraints. The pre-conditions of the activities in the business process must be same or weaker than in the CWM, while post-conditions must be same or stronger. This ensures that the constraints of the activities, as defined in the CWM, are supported in the business process. To illustrate compliance of the functional aspect, we consider the CWM of the seller in the example from Figure 1, and an excerpt of the seller’s business process (due to space limitations we cannot depict the whole business process). The contract implies (Figure 3a) that goods are to be packed by executing the activity “Package goods” with the post-condition that packaging must be done according to a given specification. In the business process, packaging of goods is designed as shown in Figure 3b.
Package Goods
(a)
compliance
Get packaging material
Packaging
Post-condition: goods are packed according to the specification ERP
Post-condition: goods are packed according to the specification
Get packaging specification
(b)
Fig. 3. Packaging of goods – in the CWM (a) and in the business process (b). The models are compliant by the result/message and the constraints rules.
In this case, the result/messages rule is satisfied, because the joint result of the three activities in the business process corresponds to the result of the CWM activity and the message exchange is equivalent (since none of the business process activities
exchange the external messages). The constraints rule is also satisfied, because the post-condition of the last activity in the business process is equivalent to the postcondition of the activity in the CWM. Behavioural Aspect. When investigating the behavioural aspect, the control flow in the business process must be compliant with the flow of activities in the CWM. It means that the business process must be able to trace all the control flow states from the CWM. This implies that the behaviour of a business process will be compliant with the behaviour of a CWM, if the business process fulfils the following rules: Ordering. In the business process, ordering of activities must be the same or stronger than in the CWM. This means, for instance, that the parallel flow in a CWM is compliant with both parallel and sequence flow in a corresponding business process. Branching. In the business process, branching must be designed such that every branching condition in the CWM has a corresponding branching condition in the business process. This means the business process may also specify additional conditional branches. Events. Events, as specified in the CWM, must exist in the business process. An exception of this rule is mapping of message-based events defined in a CWM, which denote interaction points between the partners; those events may be modelled in a corresponding business process either as events or as “receive” tasks, because both elements model an equivalent behaviour from the BPMN view. An example of the event and branching rules is given in Figure 4. In the seller’s CWM, the event that captures the buyer’s cancellation notification (Figure 4a), and the activity “Receive cancellation request” in the business process (Figure 4b), model the equivalent actions. As for the branching rule, the CWM includes two branches to model possible flows upon receiving a request for cancellation, while the business process includes an additional branch that examines the number of days passed from the receipt of order. The compliance between the CWM and the business process holds, because in the business process, the value for the number of days may be set high enough so that the task “Send request for penalty” is never triggered.
Fig. 4. Processing order cancellation - in the CWM (a) and in the business process (b). The models are compliant by the event and the branching rules.
Informational aspect. Regarding the internal process data, the CWM includes the information upon which contract flow rules are controlled (such as buyer’s address, timeframes for order cancellation, etc.). Regarding data exchanged with the external environment, as explained at the end of Section 3.3, the CWM indicates only the
messages that are to be exchanged (and not contained documents). Following this, the informational aspect of a business process will be compliant with a CWM, if the business process satisfies the following rule: Information concept. The business process must include at least the information concepts included in the CWM. This means the business process must provide required messages, and support required internal process data. The business process may support additional informal concepts not required by the CWM, in the form of messages or internal process attributes. As an illustration, in the example in Figure 1, the CWM specifies a timed-dependent condition expression (10 days) for the notification of the reject of goods, where the number of days is hold as the internal data. In Figure 5, it may be seen that the business process supports the required time attribute, which means that the rule for the inclusion of the information concept is satisfied. Transactional Aspect. By following the contract terms, a CWM specifies what are to be considered the consistent process states. For instance, a customer may agree with a travel agency that it is obliged to confirm booking of both a flight and a hotel, or if this is not possible, to notify the customer on inability to perform the bookings. The consistent states of the corresponding CWM are, therefore, those when both bookings are done, or none of them. This implies that a business process, in order to be compliant in the transactional aspect with a CWM, must satisfy the following rule: Consistent states. The business process must support either an adequate transactional model (i.e. atomic or long-running) or a “custom” error-handling flow of activities which lead to the same consistent process states as defined in the CWM. For instance (Figure 1), when the seller receives the “Goods rejected notification” the CWM specifies a compensation sub-process to be started (if the notification is sent less than 10 days after delivery). In the business process (Figure 5), the compensation procedure is implemented as a long-running transaction. However, as the consistent states are equivalent (i.e. both processes are revised to the state before packaging of goods), it means the business process is complaint with the CWM.
Fig. 5. Reject of goods in the business process; the procedure is compliant with the reject of goods in the CWM in Figure 1, by information concept and the consistent states rules.
Organizational aspect. In the CWM, the organizational aspect is represented at the level of the contracting parties, while in the business process activities are associated with the parties that actually perform those activities. The organizational aspect as
defined in a business process will, therefore, be compliant with a CWM, if the following rule is fulfilled: Role. The activities in the business process must be under supervision of the party that is responsible for the corresponding business activities in the CWM. In the example in Figure 1, it is the seller who is responsible (on the buyer’s request, as specified in the contract sample in Annexure A), to deliver the goods to a point specified in the contract (Figure 6a). In the business process, as we see it in Figure 6b, the seller contacts a transport company (the carrier) to arrange the delivery. However, as the activities of the carrier are under the supervision of the seller’s process, from the buyer perspective, the contract terms are fulfilled. In contrast, if the seller process might not support management of the delivery, such as when the seller cannot himself provide the delivery, or when it cannot supervise the delivery (as there is no communication between the seller and the carrier), the contract terms cannot be fulfilled. 4.3
Compliance Assessment
The transformation rules stated in the previous section give the possibility to assess the compliance between a CWM and a business process. The assessment requires examination of all five design aspects in order to discern whether a business process conforms to a CWM. In the following, we describe the main steps for assessing the compliance between a CWM a business process: - Examining the functional aspect, the activities in the CWM are mapped to activities in the business process, by following the result/messages rule. This means that a sub-process from the CWM will be mapped to one or more tasks in the business process. At the end of the procedure, non-mapped CWM sub-processes, if such exist, are denoted. The pre- and post-conditions of every mapped sub-processes in the CWM are further controlled against the conditions of the tasks in the business process, by following the constraints rule. Those sub-processes which do not comply with the rule are denoted. - The transactional aspect is examined by locating the transactions and/or errorhandling sub-processes in the CWM. By following the consistent states rule described in the previous section, the located elements in the CWM are compared for the compliance with the business process. If they do not lead to the same consistent process states, the CWM elements are denoted. - For the behavioural aspect, first the business process tasks that are mapped by the CWM sub-processes in two previous phases are enclosed in those sub-processes. The rest of the tasks in the business process are, if possible, “hidden” by being labelled as silent (i.e. not considered in the process flow [23]): a. All tasks that model internal business behaviour (such as “verify order”, “make goods”, etc.) could be denoted as silent, as they are neither regarded by the contract nor by the public interactions. b. The tasks that model public interaction (such as “send order acknowledge to the buyer”) are hidden from the process behaviour if they conform to the protocol inheritance notion [11].
Buyer
Buyer
As an illustration of the hiding principle we consider the example in Figure 6. The business process task “Send notification on shipment” models an interaction not specified by the contract. However, by following the notion of the protocol inheritance, the execution of a task in the sequence flow may be hidden by disregarding it (in the contrast, it would not be possible to hide a task if it follows an implicit XOR gateway, as it might prevent the execution of the other task in the gateway).
Seller
Deliver Goods
Send request for shipment/Receive notification
Send notification on shipment
Receive notification on delivery
Send notification on delivery
Carrier
Seller
Notification on delivery
(a)
(b)
Fig. 6. Deliver goods in the CWM (a); hiding redundant activities in the business process (b).
The compliance of events and gateways between the CWM and the business process is examined by applying the event and branching rules. Those elements that are coupled are labelled equally. If after the described steps all tasks are hidden, and all events and gateways are labelled, the CWM and the business process are compared for the flow equivalence using the branching bissimulation1 algorithm; if, not the conflicting tasks, events and/or gateways are denoted. - The realisation of informational aspect is examined by applying the information concept rule. The compliance of the messages is examined when the result/messages rule of the functional aspect is investigated. The internal CWM information concepts are compared for matching with those in the business process, by comparing the BPMN property elements. If some information concept from the CWM is not included in the business process, it is denoted. - For the organisational aspect, it is examined if the roles (represented with pools) that supervise the compliant sub-processes in the CWM and in the business process are same, by following the role rule. The CWM roles that might not be matched are denoted. The described procedure has the purpose to guide the process designer through the assessment of compliance between a CWM and a business process. During the assessment, each of the design aspects is examined. If all design aspects all compliant, it means the CWM may be realised with the existing business process. If not, the nonmatched CWM elements are used as a guideline on how the business process should be changed. This means that the proposed methodology may be used in the way that 1
The relation of branching bissimilarity may be used to compare observable behavior of two state-based process models, as it allows abstracting from the non-observable behavior, i.e. silent transitions. For more details, the reader is referred to [24] and [23].
the found non-compliances form a knowledge base of the elements and logic required for the process evolution (such as which activities must be added or removed; in what way the control flow should be changed; what information concepts are missing, etc.). This is especially important for tracing the “un-happy” CWM paths (i.e. exceptions, cancellations, etc.), as in the most of cases those are not supported by existing business processes due to lack of knowledge.
5
Conclusion and Future Work
In this paper, we have proposed a methodology for transforming contract requirements to concepts of processes and comparing them for compliance with existing executable business process models. Our main aim was to define an approach for bridging the contract and process domains in a comprehensive and realistic manner. To achieve that, in the contract domain, we aimed for concepts that might grasp broad contract options; in the process domain, we strived for comprising the aspects that constitute process design. We believe that our methodology, with its concepts, subsumes the following issues: − Mapping of contract requirements to process concepts. The utilization of the Multi Tier Contract Ontology as a framework for modeling contract knowledge enables identification of the states through which contract obligations are passing. By composing those states in a time-based sequence, the contract choreography (namely, the Contract Workflow Model) is obtained in the form of a high-level BPMN process model. − Traceability of contract requirements. By using the framework based on five main aspects that constitute process design, a set of compliance rules between the Contract Workflow Model and low-level (i.e. executable) business process models is defined. Those rules are used to, on the per-aspect basis, examine compliance of an existing business process with the CWM. In this way, traceability between contract terms and conditions, and existing business processes is enabled. − Process interoperability. By assessing compliance of the partners’ business processes with the corresponding Contract Workflow Models, it is determined whether those processes may realize the required contract requirements, i.e. whether they are interoperable on the level of the rules implied from the contract. In case a process is not compliant with a respective CWM, the results from the assessment might be used as a guideline for needed changes of the process, for each of five design aspects. A subject for further work is contract monitoring. Though we have not focused on that aspect in this paper, the identified mappings between the CWM and the business process can be used for monitoring the commitment fulfillment and performance analysis after each contract execution. Another subject for further research is to, by considering the suggested set of compliance rules, conceptualize the used process design framework in the form of a process ontology, and as such, employ it as a basis when comparing the CWM with the existing business process.
6 1. 2.
3. 4.
5. 6.
7.
8.
9. 10.
11.
12. 13. 14. 15.
16.
17. 18. 19.
References Daskalopulu, A., Sergot, M.: The Representation of Legal Contracts. AI and Society Vol. 11, Nr 1&2. Springer-Verlag (1997) Griffel, M., et al.: Electronic Contracting with COSMOS - How to Establish, Negotiate and Execute Electronic Contracts on the Internet. Proceedings of the Int. Workshop EDOC '98, San Diego 1998 Lee, R.: Toward Open Electronic Contracting. The International Journal of Electronic Markets, Vol. 8, Nr 3 (1998) Tan, Y. H., Thoen, W.: A Logical Model of Directed Obligations and Permissions to Support Electronic Contracting. The International Journal of Electronic Markets, Vol. 10, Nr 1 (2000) Karlapalem, K., Dani, A., Krishna, R.: A Framework for Modeling Electronic Contracts; International Conference on E-R Modeling (ER 2001). LNCS 2224 pp 193 – 207 Kabilan, V. Johannesson, P. Rugaimukammu, D. Business Contract Obligation Monitoring through use of Multi-Tier Contract Ontology. Proceedings of Workshop on Regulatory Ontologies (Worm CoRe 2003), November 2003, Italy. Springer-Verlag 2003 LNCS 2889, pp 690-702 Grosof B., Poon T.: SweetDeal: Representing Agent Contracts with exception using XML rules, Ontologies and process descriptions. Proceedings of the 12th International World Wide Web Conference (WWW2003), Budapest, Hungary. ACM (2003) Alonso, G., et al.: WISE: Business-to-Busibness E-Commerce. Proceedings of 9th International Workshop on Research Issues and Data Engineering, Sidney, Australia. IEEE Computer Society (1999) Grefen, P. et al.: CrossFlow: Cross-organizational Workflow Management in Dynamic Virtual Enterprises. International Journal of Computer Systems, Vol. 15., No. 5, (2000) Angelov, S., Grefen, P.: Support for B2B E-Contracting – The Process Perspective. 5th Int. Conf. on Information Technology for Balanced Automation Systems in Manufacturing and Services (BASYS'02), Mexico. IFIP Conference Proceedings 229. Kluwer (2002) Aalst, W. M. P. van der: Inheritance of Interorganizational Workflows to Enable Business-to-Business E-commerce. Electronic Commerce Research Vol. 2, Nr 3. SpringerVerlag (2002) ICC International contract for sale of goods, published by ICC books, 2002 Ramberg, J.: ICC Guide to INCOTERMS 2000. Understanding and Practical Use; International Chamber of Commerce (2000) IEEE’s Suggested Upper Merged Ontology, http://suo.ieee.org Kabilan V, Zdravkovic J, Johannesson P. Use of Multi-Tier Contract Ontology to deduce Contract Workflow Models for Enterprise Interoperability. Proceedings of 2nd INTEROPEMOI open workshop on Enterprise Models and Interoperability collocated with CAISE 2005, Porto Kabilan V. Contract Workflow Model Patterns Using BPMN. Proceedings of the 10th International Workshop on Exploring Modeling Methods in Systems Analysis and Design (EMMSAD 05), co located with Caise 2005, Porto. White, S.: Business Process Modeling Notation, version 1.0, Business Management Initiative, May 2004; http://www.bpmi.org BEA, IBM, Microsoft, SAP and Siebel. Business Process Execution Language for Web Services (BPEL). http://www-106.ibm.com/developerworks/library/ws-bpel/, June 9 2004. Jablonski, S. A Software Architecture for Workflow Management Systems. Proceedings of the Ninth International Workshop on Database and Expert Systems Applications (DEXA’98) (Vienna, Austria, August 1998). IEEE Computer Society, 1998, 739-744
20. Rausch-Scott, S. TriGSflow – Workflow Management Based on Active Object-Oriented Database Systems and Extended Transaction Mechanisms. PhD Thesis, Univ. at Linz, 1997 21. Bernstein, P., Hadzilacos, V., Goodman, N.: Concurrency Control and Recovery in Database Systems. Addison-Wesley, 1987 22. Garcia-Molina, H. Modeling Long-Running Activities as Nested Sagas. IEEE Data Engineering Bulletin, 14, 1, 1991, 14–18 23. Aalst, W. M. P. van der, Basten, T.: Inheritance in Workflows. An Approach to Tackling Problems Related to Change. In: Theoretical Computer Science, Vol. 270(1-2). (2002)125-203 24. Groote J. F., Vaandrager F.: An Efficient Algorithm for Branching Bisimulation and Stuttering Equivalence. In: Proceedings 17th ICALP. Lecture Notes in Computer Science Vol. 443. Springer-Verlag, (1990) 626-638
ANNEXURE A: Sample sale contract model CONTRACT FOR SALE OF GOODS Agreement made and entered into this [12th Jan 2005], by and between [ABC Computers Incorporated Ltd], of [Österogatan 17, Kista, Sweden], herein referred to as "Seller", and [Financial Movers AB], of [Strandvägen 2,Stockholm, Sweden], herein referred to as "Buyer". 1. Seller hereby agrees to transfer and deliver to buyer, within 30 days from the date of order receipt, the following goods: DELL PC Dimension 4550, Intel Pentium 4 processor, 333 MHz DDR SDRAM desktops conforming to the technical specifications. Product details specified separately. 2. Buyer agrees to accept the goods and pay for them in accordance with the terms of the contract. 3. Buyer and Seller agree that identification shall not be deemed to have been made until both parties have agreed that the goods in question are to be appropriated and fulfil the requirements of performance of said contract with the buyer. 4. Delivery shall be in accordance to standard INCOTERMS “EX-Works”. However, upon buyer’s request, the seller is obliged to make the necessary arrangements for transportation and all costs pertaining to that shall be borne by the buyer. 5. Buyer agrees to pay for the goods at the time they are delivered and at the place where he receives said goods. 6. Goods shall be deemed received by buyer when delivered to address of buyer as herein described. 7. Until such time as said buyer has received goods, all risk of loss from any casualty to said goods shall be on seller. 8. Seller warrants that the goods are free from any security interest or encumbrance, that they shall be free from it at the time of delivery, and that he neither knows nor has reason to know of any outstanding title or claim of title hostile to his rights in the goods. 9. Buyer has the right to examine the goods on arrival and has 10 days to notify seller of any claim for damages on account of the condition or quality of the goods. His failure to either notice seller or to set forth specifically the basis of his claim will constitute irrevocable acceptance of the goods. 10. This agreement has been executed in duplicate, whereby both Buyer and Seller have retained one copy each, on [12th Jan 2005]. ______________________________ [Signatures]
