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. 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 number 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 important 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 depend 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.
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:
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
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 includes 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 diagrams where a node represent an operation, while an arc indicate an order of execution. 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 understandable, 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 developers 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.
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 (
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
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
performed 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
subtracting the limiting instants (
To answer the question "How?" the process diagram should contain a detailed
description of operations that form a process. But some analysts itemize operations,
without specifying details of their execution. This approach assumes that the
performer 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
business 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 (
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 (
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 forward, bypassing some operations that speeds it up; the exceptional situations, such as client's denial from his order, unavailability of required information or technical resource. 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
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:
3.1
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 organizational chart, there is a trend to omit the role model and perform the direct assignment of employees on each operation. Such an approach can’t be considered satisfactory, since it represents a clear retreat from the model-oriented design to programming. 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 becomes 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 informational 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 (
Once candidates are selected, one of them should be resolved at run time into a
physical actor appointed to perform a task. The following strategies are available (
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
Finally, the privileges of the actor determine his right to refuse to perform the
operation or to subordinate it to another actor (e.g., vertical escalation), ask help or
consultancy from colleagues (horizontal escalation) (
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 workspace. 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 scheduling of tasks, in the second the scheduling is performed by the user.
Information model is often suspected to describe only a structure of documents
involved 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
metainformation. 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
objects 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
multiplication the single method of data integrity must be stored centrally in the object data
model (
A functional perspective is built by functional decomposition, as this is the most
natural way to analyze the system (
Modern tools for business process modeling quite wrong to ignore this perspective. 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
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 structure 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.