The paper introduces the problem of process intentionality as a basic condition for fulfilling the contents of the idea of processorientation in process models. Consequently it discusses the role of the business process modeling methodology in achieving the substantial effects of the idea of processoriented management. In this context it introduces the concept of business process patterns as a part of the Methodology for Business Process Analysis and Management (MMABP) and explains their important role in the methodology. Different conceptions and meanings of the popular concept of BP Patterns are discussed before the specific meaning of this concept in the MMABP is explained. The basic BP Pattern is described and explained in detail together with connected principles and features of the MMABP with the help of the Business Process Metamodel. Specific respect is paid to the role of BP Patterns as an expression and explanation of the most important principles and rules for modeling business process details. In the final section some wider consequences as well as future development of the concept of the Business Process Patterns in the context of the MMABP are discussed.
social, psychological, political, and other) on the other hand. The complexity of the approach is absolutely crucial there. Neglecting just one of these important aspects reliably leads to the final failure.
Consequently, the primary critical success factor of the implementation of these ideas
is an ability to mentally cover all necessary dimensions of a problem. This factor
typically causes many misunderstandings like overestimating the technical aspects of
the business process together with omitting the nontechnical ones which is typical for
IToriented people, or, in turn, ignoring the technical aspects which is typical for
managerial approaches.
Importance and popularity of the Business process management phenomenon
historically led to the creation of specialized process modeling languages and
standards. During the last two decades many different standards for business process
modeling have been created from different purposes and for different reasons. Most
of them are not in use already. Two of them can be regarded as dominant: Business
Process Modeling Notation (BPMN) [
As process modeling languages has been created by the IT community they naturally
suffer from the overestimating of technical aspects of business process and omitting
the nontechnical ones. Moreover, in terms of the approach of the leading modeling
standards UML [
One of the most important problems often occurring in business process models
which do not sufficiently respect the nontechnical aspects of business processes is a
lack of intentionality (purposefulness). As we regard this problem as crucial in
terms of process management ideas expressed in [
According to the basic work in the field of processdriven management ([
Concluding from previous two paragraphs we can find that the business process, as it is an intentional kind of a process, have to have some negative feedback which ensures restriction of its outputs in order to keep them in the margins of its goal. This characteristics strongly distinguishes the business process from the process in general (ie. in just technical /physical sense) as well as from processes which do not need any feedback like machinemanaged or automated processes running without a contact with their environment.
In case of business process feedback means some input to the process from its
environment which is causally connected with some process output. The value of
the input should influence the following behavior of the process in terms of keeping it
in the margins of its goal. This means that “intermediate” inputs to the process (i.e.
nonestarting inputs to the process coming between its starting and end points) are
critically important parts of the business process distinguishing it from other, non
intentional (i.e. nonbusiness), processes. Working with processes we have to take
into the account even the time dimension; every input to the process from its
environment has to be synchronized with the process run. Thus in each part of the
process where some input which will influence the following process run is expected
the process state has to be placed. Process state means such point in the process
structure where nothing can be done before the input to the process occurs, i.e. point
of waiting for the input. The concept of process state is present just in some process
modeling standards (like IDEF, see [
Regarding the importance of the above outlined problem together with the insufficient
support in most of process modeling standards it can be said that the primary task for
every process modeling methodology is to allow the modeling of process states
ensuring the critically important presence of the negative feedback no matter
which notation and/or modeling standard is used.
The ideas described in this paper are the part of the MMABP methodology
(Methodology for Business Processes Analysis and Design). MMABP distinguishes
between two main types of models: business process versus business object models.
In both types of model the methodology recognizes the global model (system view)
and the detailed model. The modeling tools used by the methodology are based on
common standards BPMN [
As the metamodel shows the concept of state is one of the crucial concepts in the
methodology. Besides the fact that it is one of three basic process elements (together
with stimulus and activity) it plays the specific role of “connector” of two main kinds
of process activities: processing activity and control activity. This fact is closely
connected to the concept of negative feedback according to the definition in [
In the field of objectoriented analysis and design this concept has been introduced
already in 1992 by Peter Coad [
In the field of business processes the concept of patterns is most frequently used in
the context of workflow management. The most visible initiative in this area is the
Workflow Patterns project [
HansErik Eriksson and Magnus Penker in [
There are several definitions of the concept of pattern in the field of analysis, for
instance: "an idea that has been useful in one practical context and will be probably
useful in others" [
There are two main kinds of Business Process Patterns in the MMABP methodology: • Basic Business Process Flow Pattern which defines the basic procedure and decision points of the process of model creation. This pattern is absolutely essential in the MMABP, it expresses the main principles, rules, and other aspects of the MMABP approach to the business process modeling and therefore it is explained in detail in this paper. • BP patterns for particular situations which cover typical situations frequently occurring in business process models where it is possible to find some generally valid structures, principles and constructions which should be fulfilled by the process description undoubtedly. There are three most general patterns: Complementary Events Pattern, Repeating State Pattern, and <<inclusive OR>> Pattern. As the complementary patterns for particular situations are not so closely connected with the problem of process intentionality as the basic pattern we do not pay more attendance to them in this paper.
The Basic Process Flow Pattern expresses the basic structure of the process model
which respects the essential rules of the MMABP methodology. These rules express
the "technical" necessities which mainly follow from the general theory of algorithms
as well as the specific aspects of the business process which distinguish the business
process from a process in general (i.e. just technical) sense. The lately mentioned
rules follow from the theory of BP management and reengineering which is anchored
already in the basic work in this field: [
Activity block
State block
Activity block Starting Event block End state
Basic Process Flow Pattern (see Fig. 2) expresses the essence of the process flow using three methodically essential types of the process elements: events, activities, and states.
According to the Basic Process Flow Pattern the business process should be
described as a sequence of Activity blocks interrupted by State blocks starting with
just one Starting Event block and resulting in one or more End states. Fig. 3 illustrates
an exact definition of these basic blocks. The definition is written in the semiformal
metalanguage based on the simplification of the standard Extended BackusNaur
Form (for details and explanation of the EBNF see [
• A = { elementX } means that the item A consists of one or more elementsX. Particular definition sentences can be read as follows:: Def (i): Process flow begins with starting Event block followed by the Process
Body.
Def (ii): Event block is either a single event, or structure of mutually exclusive
Event blocks, or structure of mutually synchronized Event blocks.
Def (iii): Event can be either an adhoc event or a timer.
Def (iv): Process body consists of one or more pairs where each pair consists of an Activity block followed by either State block or End State. If the pair ends with State block the description should continue with another pair (see the arrow after the State block). End state always means the end of the process. Def (v): Activity block is either a single Activity, or structure of mutually exclusive
Activity blocks, or structure of parallel Activity blocks.
Def (vi): State block is a synchronization of internal process flow with expected event(s) expressed as an Event block (in other words: waiting for the event(s)).
Event block represents the external influence which the process always has to respect. It works either as a trigger or a limiter of the process. In both cases it has to be unambiguous which means, among others, that is has to represent a single point of time. Therefore it can be either a single event or a timeelementary structure of events. If it is a structure it can express either the synchronization of parallel events (event blocks) or the set of possible mutually exclusive alternative events (event blocks) in order to be timeelementary.
Activity block represents an action element of the process. It can be either a single activity or a structure of activities (activity blocks). Similarly as in the case of event also an activity should be unambiguous. Therefore, if it is a structure, it can express either the synchronization of parallel activities (blocks) or the set of possible mutually exclusive activities (blocks). It cannot express a sequence of activities as it would be a violation of the elementariness rule. The methodical reasons and meaning of the need for the elementariness of activities in the process description is discussed in more detail below.
State block represents the essential need to synchronize the process run with expected events. This need follows from the fact that the event is always an objective external influence and thus it must be respected. From the physical point of view such respect means synchronization – waiting for the event (event block). As the BPMN notation do not recognize the concept of process state there is no other way than to express the process state with the general symbol for synchronization – the "AND gate". In order to distinguish between the general synchronization and its specific meaning as a process state we complete the BPMN with the stereotype <<process state>>.
One of the most important ideas expressed in this pattern is that there can not be a sequence of process activities uninterrupted by the process state. This rule reflects the essence of the definition of an elementary process activity: (a) the process activity is regarded as an elementary one if there is no objective reason for its interruption, (b) the reason for the interruption of the activity is objective if it comes from outside of the process.
Rule (b) of this definition means that each objective reason for the process interruption is represented by an event (external influence) in fact. Thus any activity of the process, no matter how technically complex it is, must be regarded as elementary if there does not exist an external influence (event) which the process has to respect (i.e. wait for). This consequence well illustrates the fact that the elementariness of a business process activity is not only its physical but much more a functional attribute as the business process itself is always more than a physical process (algorithm) only. This way the methodology prevents the analyzer from the pointless unlimited dividing of the process activities which is a frequent mistake in the field of BP modeling. The necessity of such safety fuse in the methodology against the unlimited division of activities is given by the fact that in the field of processoriented modeling the aggregation is a dominating type of abstraction (unlike
E2 E1
A1 <<process state>>
A2 A3
A4
A5 End1 state in the field of objectoriented modeling where the generalization is a dominating type of abstraction). This fact manifests itself in the principally unlimited possibilities of division of activities known as a rule: any single process activity can be decomposed into the structure of subactivities – a process (as it is also defined by the process metamodel at Fig. 1). As the division of activities is physically unlimited the methodology has to define some logical – functional definition of the very low level: the level of the process elementariness.
activity activity state activity This paper presents the role of the business process modeling methodology in achieving the substantial effects of the idea of processoriented management. It explains the importance of process intentionality as a basic condition for fulfilling the contents of the idea of processorientation in process implementation. In this context the paper introduces the concept of business process patterns as an important part of the business process modeling and management methodology. The popular concept of pattern is widely used in many different meanings. The common value of this style of presenting in all areas which makes it so popular is the possibility to express important rules a very understandable way. The MMABP business process patterns are specific by their focus on the rules for modeling business processes which include the technical aspects of the process modeling together with the content aspects which follow from the theory of process based management. The essence of these methodology rules is expressed in the Basic Process Flow Pattern which explains how the way of modeling the process should generally respect the main ideas of the process oriented management. The system of patterns has been added to the MMABP based on the experience with its use in dozens of business process modeling projects. Further experience confirmed the importance and suitability of this form of methodical support especially for its integration effect: it naturally integrates different methodical principles in different, mutually connected, views on the business process system. Respect to states between activities in the form of waiting for the external event leads the modeler to the respect to associations with other processes which are giving the process the meaning of the part of the process system. Prohibition of the sequence of activities without a state between them underlines the methodical idea that the prime purpose of the process description is to map the human influences in the process (decision mechanism) instead of the unimportant sequence of activities which is ensured by the technology. The process management means primarily the way of management instead of the technology. Other mentioned patterns support the methodology ideas in typical specific situations. These partial purpose patterns complete the basic process flow pattern and should be understood strictly under given methodology assumptions. Moreover, their development is principally unlimited; as the evolution of the methodology goes on together with the penetration of specific areas of its application the number of these specific purpose patterns will increase as well.
Acknowledgments. The work presented in this paper has been supported by the Faculty of Informatics and Statistics of the University of Economics, Prague in the project IP 400040.