**5.3. Iteration vs. no iteration**

118 Petri Nets – Manufacturing and Computer Science

**Figure 7.** Business Process vs. Workflow

explicitly in the model of case semantics.

A business task can be characterized by

1. Recording the receipt of the claim;

the second task must be included.

number for sorting and searching B-forms later on.

short.

**5.2. Management task vs. business task** 

A selection is required at a crossing point of different routes. Concrete data of a given case determine the selection. The so selected route is the "semantics" of the given case. Thus, case semantics is concerned with those data that are used to decide whether a business task is on the route to be selected. These data are called explicit data since they should appear

A business must have a pre-designed form (paper form or electronic form) to record how an individual case is initiated and processed. Such a form is called a business form, B-form for

1. It requires professional knowledge, skill and/or experience related to the business. 2. It fills in at least one blank assigned to it on the B-form to tell what has been done.

A management task, on the other hand, requires knowledge on management rules. If it fills in blanks on the B-form at all, the written content is for management need only, e.g. a serial

In the book *Workflow Management*, 16 tasks have been listed for "insurance claim" business

2. Establishing the type of claim (for example, fire, motor vehicle, travel, professional).

The first task may assign a serial number to the claim. Otherwise, it would leave no trace on a B-form. In fact, it is even not concerned with what B-form to be used. The second task must fill in the blank "type of claim" at least. Thus, the first task is a management task (may be shared by all businesses in a company) while the second task is a business task. In other words, the first task should be excluded from the workflow logic for "insurance claim", but

in a (fictional) insurance company, among them, the first two tasks are:

The author of *Workflow Management* wrote: "This example of a process (i.e. insurance claim) also includes iteration or repetition — namely, the repeated assessment of an objection or the revision of the amount to be paid. In theory, this could go on forever."

As a management rule, an objection to a claim may need to be assessed more than once, but it must be a fixed number of times and by different persons; furthermore, the conclusion of each assessment must be recorded on the B-form. In other words, reassessment is a different task rather than a repetition of assessment.

Mathematically or logically, repetition could go on forever, but not for a theory of management. Endless repetition is not even thinkable in a management theory.

Iteration or repetition implies "redo" of the same task, i.e. what has been written on the Bform should be erased. "Redo" caused by wrong doings could, in theory, occur for every single task since human beings are erroneous by nature. No one would suggest a repetition for every task in a workflow model. "Redo" is nothing but a management measure to heal wrong doings, not a normal portion in a business process. Besides, workflow logic is about abstract tasks, but iteration is case dependent.

Endless redo could not occur since it is under control of the engine.

The execution of a single business task may include iteration. For example, when the amount of goods exceeds the truck load, the truck(s) would have to return after unloading. Such iteration is the detail of task execution, not a measure of management. Besides, it is case dependent. Iteration has nothing to do with workflow logic. What case semantics is concerned with is whether a task is on the route, not how a task is executed.

## **5.4. Set of tasks vs. set of blanks on B-form**

Let T = {t1,t2,…,tn} and B = {b1,b2,…,bm} be the set of business tasks and respectively the set of blanks on the B-form for a give business process. The investigation here aims at properties of T and B for a well-defined business process.

There must be a correspondence between T and B, telling which blank(s) each task is responsible for. This correspondence should guarantee that no more than one task is responsible for the same blank in the course of processing a single case, and no blank is left empty upon termination of the case processing ( those blanks that are not in relation with a given case are assumed to have been crossed out by the engine). Such correspondence has become common sense today. We will say no more about it.

Causal dependence among tasks in T leads to a combinatorial acyclic partial order on T:﹤ ⊑T×T , and a sub-relation < of < : x<y ≡ x<y ∧∀z∈T:¬(x<z∧z<y). < is the "immediate successor" relation: y is the immediate successor of x. Since the ordering relation < is derivable from < by transitivity of <, we will talk about (T, <) instead of (T, <). No iteration among tasks in T leads to acyclic partial order.

Let u be a task in T, u is a start task if it is before every other task, i.e. ∀t∈T:¬(t<u); u is an end task if u has no immediate successor. It is assumed that there is a unique start task, i.e. all cases share a unique beginning to recognize and to accept a case.

Workflow Modelling Based on Synchrony 121

A place p in a RP/T-system is a synchronizer if T1 and T2 are the pre-set and post-set of p and they are not empty; and ∀t ∈ T1: W(t, p) = b and ∀t ∈ T2: W(p, t) = a where b and a are integers such that 0≤ a ≤ n and 0≤ b ≤ m ; n, m are respectively the numbers of transitions in

The RP/T-system in Figure 2 has two synchronizers p1 and p2 since K(p1) = 2 and K(p2) = 2.

The synchronizer defined by Definition 10 is usually denoted by p = ( T1, T2, (a, b)) or p =

detail of p, explaining how synchronization is achieved. Theorem 4 concludes that σ(bT1, aT2) = ab, i.e. the weighted synchronous distance between T1 and T2 are ab where b is the

Let p = ( T1, T2, (a, b)) be a synchronizer and n, m be the numbers of transitions in T1 and T2.

Here we have deliberately chosen terms used by Prof. Aalst for WF-net. The difference is, our synchronizers are places while synchronization is achieved via transitions in WF-net. Synchrony in Section 3 has made it clear that synchronization with a distance greater than zero is place synchronization. We will see what advantages the concept of synchronizers

weight for all transitions in T1 and a is the weight for all transitions in T2.

, (a, b)). Figure 8 (a) is the graphical presentation of a synchronizer p and (b) is the

**6.1. Synchronizer** 

T1 and T2; and K(p) = ab.◆

**Figure 8.** A Synchronizer and its Detail

n=m=1, p is sequential synchronizer,

brings with it when we approach to management logic.

P can be classified as below:

a>1 and a=n, p is an ALL-join,

1<a<n, p is an OR-join, a=1 and a<n, p is a XOR-join, b>1 and b=n, p is an ALL-split, 1<b<m, p is an OR-split, b=1 and b<m, p is a XOR-split.

Definition 11

m>1, p is a split, n>1, p is a join,

Definition 10

( . p, p.

Let T1, T2 be nonempty subsets of T. T2 is called an immediate successor set of T1 , denoted by T1<T2, if ∀u∈T1∀v∈T2:u<v. It is easy to prove that T1 and T2 are disjoint, and tasks in T1 (T2) are not ordered. Synchronization for management need can only be introduced between T1 and T2. Here, the synchronization between T1 and T2 must be place synchronization since they are different transitions. In case T1 and T2 are both singletons, the synchronization can only be the immediate successor relation. As an example, let be T1 = {a, b} and T2 = {c, d}, σ(T1,T2)=2 and σ(T1,2T2 )=2 are two different ways of synchronization. Taking into account the fact that every task, if it is included on a route, can only be (effectively, redo is not counted) executed once, σ(T1,T2)=2 requires that tasks a ,b being executed in parallel followed by tasks c, d being executed in parallel; σ(T1,2T2)=2 requires that tasks a, b being executed in parallel followed by either task c or task d being executed alone. Data from a given case will be used for the selection between task c and task d. It is clear that synchronous distances would be of no use if redo is taken into account.

Now the processing of a given case goes like this: it begins from the unique start task, each task on the route carries out its duty and fills in blank(s) it is responsible for on the B-form, and passes it to its immediate successor(s) via the engine. The engine takes care of quality checking, successor selection and appointing executer(s) for selected task(s); and finally, the engine passes the B-form to appointed executer(s).
