**5.1. Business process vs. workflow**

A business process is a pre-designed process in an enterprise or an organization for conducting the manipulation of individual cases of a business. It existed even before the birth of computers. The manipulation of individual business cases consists of business tasks and management tasks. The concept of "workflow" aims at "computerized facilitation or automation of a business process, in whole or part" (WFMC). To this end, the separation of business tasks and management tasks is of first importance. In a way, this is similar to the separation of data processing from a program, leading to the concepts of databases and database management systems.

A single business task may be carried out by a computer program. But "computerized automation of a business process" focuses on management automation rather than task automation. Management automation relies on clearly specified management rules. Most of the rules apply to all cases while some of the rules apply to individual cases. The former is "workflow logic" and the latter is "case semantics". The purpose of workflow modelling is nothing but to establish a formal specification of management rules to serve as a guide in the design, implementation and execution of a computer system called "workflow engine". It is the execution of the engine that conducts the processing of business cases. Figure 7 illustrates how workflow is related to business process.

The workflow logic specifies how business tasks are ordered (for causally dependent tasks) and/or synchronized. But, ordering is also a way of synchronization. Thus, workflow logic specifies how business tasks are synchronized for all conceivable cases in a business. In other words, workflow logic specifies all possible routes that a business case may take when being processed. What workflow logic cares about a single business task is not what data it requires or what data it will produce, let along what exact values are inputted or outputted. In this sense, workflow logic is concerned with abstract business tasks only.

118 Petri Nets – Manufacturing and Computer Science

Workflow Modelling Based on Synchrony 119

**5.3. Iteration vs. no iteration** 

task rather than a repetition of assessment.

abstract tasks, but iteration is case dependent.

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

of T and B for a well-defined business process.

among tasks in T leads to acyclic partial order.

become common sense today. We will say no more about it.

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

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

Mathematically or logically, repetition could go on forever, but not for a theory of

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

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

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

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

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

the revision of the amount to be paid. In theory, this could go on forever."

management. Endless repetition is not even thinkable in a management theory.

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

concerned with is whether a task is on the route, not how a task is executed.

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

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 explicitly in the model of case semantics.
