=Paper=
{{Paper
|id=Vol-1989/paper54
|storemode=property
|title=A structure of a business process executable model
|pdfUrl=https://ceur-ws.org/Vol-1989/paper54.pdf
|volume=Vol-1989
|authors=Igor Fiodorov
}}
==A structure of a business process executable model ==
https://ceur-ws.org/Vol-1989/paper54.pdf
A Structure of the Business Process Executable Model
Fiodorov Igor Grigorievich
Dr.Sci., professor
Plekhanov Russian University of Economics (PRUE)
Russia, Moscow, Nezhinskaya str., 7
Igor.Fiodorov@mail.ru
Abstract. A business process model has layered structure, formed by several
perspectives, the later can be split into separate aspects. Knowledge of a thin
structure helps an analyst in creating exact models.
Keywords: process model, process perspectives and aspects
1 Introduction
Yet there is no single and common definition what is a business process model
(1). Different categories of users apply this term for dissimilar things like VISIO
flowcharts, EPC and BPMN diagrams, even BPEL, despite their differences. Some of
models used for business analyses give only a very general representation of use case,
another, used for automation, include all possible paths of process execution. A num-
ber of models have low level of detail and show only main functions, others go deep
to the level of elementary actions. The absence of unified understanding provokes a
conflict when user gets a model that doesn’t meet his expectations. So it is very im-
portant to define all ingredients of the process model.
Different researchers consider a process model consist of a number of perspectives.
A CIMOSA model have four perspectives (2) while Zachman name six well known
layers (3), ARIS integrated model mention three main perspectives while fourth de-
pend on the goal of modeling (4). In this work we will follow B. Curtis who considers
a process model as integrated representation that unites four perspectives (5):
─ Behavioral: describe the dynamics of process execution;
─ Informational: describe the business entities subject area;
─ Organizational: describe the distribution of work between the performers.
─ Functional: describe the structural decomposition of work;
In our understanding each perspective consists of layers, we call them aspects. In this
paper we investigate the aspects of four process perspectives.
128
2 The behavioral perspective
The Behavioral perspective describes system in dynamics. It answers a question
«How the work has to be done». Let split the question How in to three sub questions:
1. In which order the operations are executed?
2. At what time are the operations started, how long do they last?
3. Why are the operations executed in a particular order?
The answer to the first question is business logic, which is a procedural description of
the order of process execution. The second question is answered by the timetable
which adds temporal relations between operations. Finally the answer to the third
question is business rule that explain the reasons of the decision. In this way we have
divide the behavioral perspective in to three aspects. Each of these aspects should be
reflected in a model. Let us examine these aspects in details.
2.1 The business logic aspect
Business logic is a procedural description, it contains explicit, prescribing information
about the route of execution of the process, but only indirectly takes into account the
criteria for making appropriate decisions. The description of the business logic in-
cludes the branching element, which allows you to route the process execution to one
of the predefined paths in accordance with predefined conditions. Branching is an
element of the business logic while the condition by which branching occurs is a
business rule. Usually the business logic is modeled by means of a workflow dia-
grams where a node represent an operation, while an arc indicate an order of execu-
tion. Some of operations transform the input data flow into the output, while others do
not change flow but route it. For example, logical operator that branches the process
flow do not modify the data and routes it in accordance with the specified condition.
Thus logical operators are elements of the business logic, while a criterion of routing
is the business rule. Usually the business logic includes an explicit information about
the route required, but exclude criteria for making a decision.
The diagrams that describe the business logic visually seem simple and under-
standable, since they does not include full set of business rules, time schedule, control
actions taken when the process parameters go beyond the threshold, so many analysts
use them to align with the business. However, the simplicity is deceptive, IT develop-
ers have to re-collect the missing information and their understanding of the process
may differ significantly from those of the analyst. There is a dangerous situation: the
model does not fully describe the process, details are not explicitly recorded and exist
in a minds of programmers, which is one of the reasons why the model of the process
on paper does not match the logic of the IT system.
129
2.2 Business rules aspect
A business rule is a statement that defines or constrains some aspect of the business.
In contrast to procedural descriptions, rules posit the limitations on the execution of
the process, but do not specify how to achieve the expected result. As shown above,
the logical operator represents a work and belongs to the business logic, while the
condition of the routing is the business rule. Similar routing criteria may be found in
some other operations, for example in an event it can keep a rule of a time, etc.
R. Ross proposes the following classification of business rules (6):
• Behavioral Rule: a rule that there is an obligation concerning conduct, action, prac-
tice, or procedure. Behavioral rules are about what people must or must not do.
• Definitional Rule: a rule that is intended as a criterion giving a necessity about the
meaning of some concept. They do so in two basic ways:
─ Computation rules provide decision logic to perform calculations.
─ Classification rules provide decision logic needed to determine whether or not
something is true.
The behavior rule routes the process execution, so we categorize it as business logic.
The behavior rule is based on the routing criterion that takes the values true or false.
What is true and what is false is determined by the classification rule. In turn, the
latter should receive an input value, obtained using the computation rule. However, a
common practice of process modeling is to fix the behavioral criterion forgetting the
definitional one. The absence of some definitional rules makes the process model
incomplete. Another mistake is to combine all rules in the routing element on the
process diagram, which makes more difficult to modify a decision.
2.3 The time aspect of process execution
In the field of material production a Gantt chart is used to calculate the time required
to manufacture the product and in this way determines a production time table. For
business processes the time table is more complex, since each operation can be per-
formed in time, while the whole process delay due to returns backward to reprocess.
The ontology of time used to describe the temporal relations between the operations
that make up the process uses two basic concepts: time instant and time interval. Time
instant is the main primitive element and it provides the means for identifying a point
on a timeline that has no duration. Time interval is defined by means of start and end
instants and has therefore an associated duration which can be calculated by subtract-
ing the limiting instants (7). In the business process modeling the time instant is asso-
ciated with an event. The event is used to coordinate the execution of various process-
es. A time interval is associated with a timer that limits the execution or the waiting
time. Some modeling methodologies consider that the event is fixing a fact that in-
formation object have change (8) and thus they mix the Event with a State of the ob-
ject. The first one can be associated with a time instant while the second can’t.
130
2.4 The Level of Detail of the Process Logic
To answer the question "How?" the process diagram should contain a detailed de-
scription of operations that form a process. But some analysts itemize operations,
without specifying details of their execution. This approach assumes that the perform-
er knows how to do the operation. However, an employee tends to perform his work
based on an individual experience gained in a company with a different organizational
structure or corporate culture, which leads to variability of the execution. The busi-
ness process may consist of nested reusable components called sub-processes. No
need to assume that each sub-process is a new level of decomposition and thus limit
the depth of breakdown to five – seven, as it is recommended by SADT (9).
We will distinguishing an operation and a task. The operation results in the change
in a state of information object being acted upon while the task outcomes in the
change of an attribute of the same object (11). Let's try to clarify this definition for a
case of process modeling. Work done in the process is recorded in the information
object that can be associated with a process state variable which can take qualitative
and quantitative states. The task is a unit of work performed by a participant on the
information object that quantitatively modifies that object, but not leading to a quali-
tative change of its state. For example, a participant has introduced new data, but this
does not mean the end of the document processing. The operation is called a set of
tasks that change a qualitative state of that information object. While in the analytical
modeling the level of operations would be quite sufficient, in the executable process
modeling we must strive for the task level of detail.
2.5 The degree of business process logic completeness
Note that the majority of workflow diagrams present a limited number of execution
scenarios, specify only the most obvious routes by which the major number of process
instances are executed, forgetting that in reality there are many other alternative cases:
backward transitions for re-processing that slow down the execution; transitions for-
ward, bypassing some operations that speeds it up; the exceptional situations, such as
client's denial from his order, unavailability of required information or technical re-
source. A process diagram presenting use case is useful for a functional information
system development, where a human determines the order of execution. But for a
process-oriented system development, where the order of operations is determined by
the diagram, the model should cover all possible scenarios; otherwise the operation
would become impossible.
3 The organizational (resource) perspective
Organizational perspective describes the dynamics of the enterprise, in contrast to the
organizational structure, which shows the static distribution of a workforce between
business units. The organizational perspective includes four aspects that are important
for the business process execution:
131
1. How to select candidates for the execution of each operation?
2. Which of candidates should be appointed as an executor?
3. What are privileges of the executor, appointed to the task?
4. In what order the executor can performs tasks assigned to him?
3.1 The aspect of the grouping
The nomination of candidates for the operation was traditionally carried out using a
role model. However, due to the difficulties with the mapping of roles on the organi-
zational chart, there is a trend to omit the role model and perform the direct assign-
ment of employees on each operation. Such an approach can’t be considered satisfac-
tory, since it represents a clear retreat from the model-oriented design to program-
ming. Problems with mapping of the role model on to the organizational structure
stems from the fact, that the process-oriented model of the work is mapped on the
functionally-oriented organizational structure. There is a contradiction between the
process organization of labor and functional organizational structure. Instead of the
role the analysts use a job position or an organization unit. As a result the actor be-
comes bind to the organizational structure of a specific company. That does not meet
the original purpose of the role model. The essence of the role should be viewed from
two points of view: the business modeling and access rights. In a business modeling
the role means a group of actors who can be assigned on the specific operation. In the
IT the role means the group of the participants who have similar rights to access in-
formational objects of an IT system. These definitions do not contradict each other, so
business analyst should keep track both.
Let consider the grouping from the perspective of management theory.
H.Minzberg (12) proposes to define the organization structure as the way in which the
labor process is first divided into individual work tasks and then is coordinated. He
uses the grouping of the following criteria: (a) by processes; (b) by work tasks (func-
tions); (c) by qualification and skills; (d) by the time of work (shift); (e) by the prod-
uct of the process; (f) by the clients of the organization; (h) by the place of work. Let
use his criteria. The grouping by a process allows selecting all actors involved in this
process. The confusion arises from the grouping by functions. In the functionally-
oriented company this grouping is used to structure organizational units. This gives a
cause to analysts to bind a function to a unit or to job position, which can cause a
mistake. For example, an employee and his manager can perform the same operation,
respectively they are located in the same role, while working in different positions.
Therefore, the grouping by functions should be seen as a first step of grouping actors
who are assigned on the specific operation. To distinguish between employee and his
manager we should use the additional criteria of grouping. As mentioned above, it
could happen that two participants in one role should not see the work of each other.
For example, sellers in different territorial units can’t see the process instances of
each other. In this case, the grouping by the place of work helps to clarify the group-
ing by function and thus extend the definition of the actor's access right. Similarly,
one can use other kinds of grouping and thus precise the participant's access rights.
Thus, the procedure for selecting candidates to perform the operation reduces to find-
132
ing the participants, who belong to the respective groups at the same time. In mathe-
matical terms, this means the need to find the intersection of several sets, each of
which describes the appropriate group. At the same it is necessary to provide a situa-
tion when the resulting subset is empty. In last case, for example, the appropriate
manager can manually assign an actor.
3.2 The aspect of the assignment of the actor
Once candidates are selected, one of them should be resolved at run time into a physi-
cal actor appointed to perform a task. The following strategies are available (13) (14):
1. Task is given to all of selected candidates and one will select himself;
2. The actor is manually nominated by the manager;
3. Actor is selected based on process instance performance indicators:
- Given the execution time of the process (shortest process time, shortest rest-
processing time, earliest due date)
- Given the history of execution (to one who has already participated, to one
who has not yet participated).
4. Actor is selected based on the process participants performance indicators (ac-
cording to the current workload or overall production for the period)
Selecting the executor we should consider the situation when the selected actor will
be absent from work for a long time, so someone should be appointed temporarily to
perform his duties.
3.3 The aspect of privileges of the actor appointed to the task
Finally, the privileges of the actor determine his right to refuse to perform the opera-
tion or to subordinate it to another actor (e.g., vertical escalation), ask help or consul-
tancy from colleagues (horizontal escalation) (16). A common mistake is to associate
these privileges with an organizational position only, while in a process company they
can be based on temporary workgroup etc. The logical people grouping can help to
resolve the necessary organizational hierarchy.
3.4 The aspect of task execution order
The last aspect specifies the order in which the executor will select his tasks from the
task list. Typically, the user selects a first one item from his task list located in work-
space. By default, the task list is sorted in a way that process instance that came first
is at the top of the list and the last one appears at the end. However, the order can be
changed by manipulating the priority of the process instance. Thus, instances that are
late can receive a higher priority and will appear at the top of the task list so will be
selected for execution first. Alternatively a user can have a right to select any task
from his list despite the order. In the first case a system is responsible for the schedul-
ing of tasks, in the second the scheduling is performed by the user.
133
4 The aspects of the informational perspective
Information model is often suspected to describe only a structure of documents in-
volved in the process, actually it has four aspects.
─ The structural aspect defines the relationships between documents and among data
objects. Documents of the process can be divided into structured and unstructured.
The last are stored as an image and are enclosed with a context the meta-
information. Different structured documents can contain common information so
that data entered in one document can be available in the other. To describe the
structural aspect we use an object hierarchical data model. This model is no equal
to database schema, but shows conceptual relationships between the individual ob-
jects and methods.
─ The aspect of static integrity determines the permissible range taken by the data
values, e.g. the maximum and minimum value of a parameter. Some developers
place a check of the input data to an appropriate screen forms. It turns out that one
check method can be repeated several times in many forms. To avoid multiplica-
tion the single method of data integrity must be stored centrally in the object data
model (15).
─ The aspect of dynamic integrity appoints the right to see and modify the data ob-
jects at different process steps. For example, entering an order you can update and
modify the information about the customer, but on the next steps the changes are
not possible. Centrally storing the methods of dynamic integrity simplifies mainte-
nance and modification of the process screen forms.
─ Information flow, that accompanies process execution, is formed by information
object that pass between process steps, captures the execution result of a current
operation, a process stage or an entire process and thus connects inputs and out-
puts. We associate this object with a state variable that determines the status of the
system at a given time. The BPMN 2.0. specification use the concept of sequence
flows, but does not define it explicitly. For ease of reading it introduces a token that
traverse the sequence flows. The token is defined as a "theoretical concept" and is
used to determine the behavior of the executable process (16), unfortunately it not
explained. Now we can interpret the token as the state variable that is moving
along the process and in this way determines the temporal order of the process exe-
cution.
5 Functional Perspective
A functional perspective is built by functional decomposition, as this is the most natu-
ral way to analyze the system (9). The model can be seen as a work breakdown struc-
ture that list all units of work but doesn’t indicate a temporal order of the execution. A
functional perspective is a strong tool to analyze a process, it shows a system in a
statics, answers a question “what should be done to achieve a goal?” It is believed that
134
having a full set of functions one can build a system using reusable components. The
strength and benefit of functional perspective is because it is produced top down.
Modern tools for business process modeling quite wrong to ignore this perspec-
tive. If an analyst need to add the activity in the workflow diagram, he must first find
a place for this unit of work on a functional decomposition. This will help to avoid
duplicated and skip functions. Identify missing or duplicated function in the workflow
diagram is much more laborious because two operations that correspond to these
functions can be located far from each other.
6 Conclusions
The novelty of this paper is in defining a thin structure of a business process model. It
extends existing theory of model perspectives by defining their layered configuration.
Knowledge of a process thin structure is practically important as it explain an analyst
what model consists of and where these details must be located. An analyst, who have
no knowledge of a thin structure, use to eliminate some of the aspects, thus making
model incomplete, or locate them in a wrong place within a model, which makes it
difficult to understand. We consider both cases to be a glaring mistake and believe
that can help in avoiding these errors.
It is obvious that any modeling notation is not capable of presenting a thin struc-
ture in a whole. The limitations on this paper do not allow us analyze expressiveness
of particular business process modeling languages, that would become an extension of
a current research.
References
1. The Aspects of Business Processes: An Open. Axenath, B., Kindler, E. and Rubin, V. :
Computer Science Department of the University of Paderborn, April 2005. Technical
Report tr-ri-05-256.
2. Enterprise Integration: On Business Process and Enterprise Activity Modeling.Vernadat
F.: Concurrent Engineering: Research and Applications, 1996.
3. Zachman J. The Zachman Framework For Enterprise Architecture.
4. Scheer, A.W. Architecture of integrated Information Systems . 1992.
5. Curtis, B., Kellner, M. and Over, J. Process Modeling. Communications of the ACM. 1992,
Vol. 35, 9, pp. 75-90.
6. Business Rule Concepts: Getting to the Point of Knowledge. Ross R. 2009.
7. A Core Ontology for Business Process Analysis, Proceedings of the 5th European
semantic web conference on The semantic web: research and applications. Pedrinaci, C.,
Alves de Medeiros, A. and Domingu, J. Berlin, Heidelberg : SpringerVerlag, 2008.
8. Methods ARIS 7.0. Saarbrücken : IDS Scheer AG, 2005.
9. McGowan C., Marca, D. SADT: structured analysis and design technique. NY : McGraw-
Hill Book Co., Inc., 1988.
10. Aitken C., Stephenson C., and Brinkworth R. Process Classification Frameworks. In vom
Brocke J. and Rosemann M. Handbook on Business Process Management 2. Berlin
Heidelberg : Springer-Verlag , 2010.
135
11. Mintzberg H. Structure in fives: Designing Effective Organizations. s.l. : Prentice Hall,
Inc, 1983.
12. A BPMN 2.0 Extension to Define the Resource Perspective of Business Process Models. .
Stroppi L., Chiotti O., Villarreal P.: 3er International Workshop on the Business Process
Model and Notation , 2011.
13. Enabling Resource Assignment Constraints in BPMN.Awad A., Grosskopf A., Weske M.
2009 : BPT Technical Resport 06-2009.
14. A vocabulary and execution model for declarative business process modeling. Goedertier
S., Haesen R, Vanthienen J. s.l. : EM-BrA2CE v0.1.
15. OMG. Business Process Model and Notation (BPMN) Version 2.0. 2012.
http://www.omg.org/spec/BPMN/2.0.
16. ITU. ITU-T Recommendation X.906 | ISO/IEC 19793. Information technology – Open
distributed processing – Use of UML for ODP system specifications. Montréal, Canada :
2004.
17. Supply-Chain Council Inc. Supply-Chain Operations Reference-model. Pittsburgh : s.n.
www.supply-chain.org.