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
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.
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 (6):
• Behavioral Rule: a rule that there is an obligation concerning conduct, action, practice, 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.
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 (7). In the business process modeling the time instant is associated with an event. The event is used to coordinate the execution of various processes. 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 information object have change (8) and thus they mix the Event with a State of the object. The first one can be associated with a time instant while the second can't.
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 (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 qualitative 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.
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 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.
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:
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?
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 (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: The grouping by a process allows selecting all actors involved in this process. The confusion arises from the grouping by functions. In the functionallyoriented 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 grouping 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-ing the participants, who belong to the respective groups at the same time. In mathematical 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 situation when the resulting subset is empty. In last case, for example, the appropriate manager can manually assign an actor.
The aspect of the assignment of the actor 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 (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 restprocessing 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 (according 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.
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 operation or to subordinate it to another actor (e.g., vertical escalation), ask help or consultancy 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.
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.
The aspects of the informational perspective
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 (15). ─ The aspect of dynamic integrity appoints the right to see and modify the data objects 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 maintenance 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 outputs. 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 execution.
A functional perspective is built by functional decomposition, as this is the most natural way to analyze the system (9). The model can be seen as a work breakdown structure 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 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 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.
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.