Current environments are dynamic. For surviving, organisations should be adaptable to and interoperable with these environments; their Business Processes (BPs) have to provide means to suit the effectiveness requirements. The most important success factors are flexibility and adaptability. Situational engineering has proved its effectiveness, in terms of flexibility and reuse, in many engineering domains such as software and IS development. So reasoning on a situational approach is a challenging research work which can contribute to increase flexibility of models and their adaptability to different organisation settings. The paper deals with creating meta-models for BP modelling which adapt to the situation at hand.
Current researches on business process (BP) modelling stress the importance of the flexibility and the adaptability support for BP (see for instance [8], [28], [33]). [20] provides a survey on the flexibility requirements related to BPs and modelling artefacts. Reasoning on variability in modelling artefacts can meet the flexibility and context-awareness requirements by offering alternative solutions depending on the context and on the points-of-view of the decision-makers. We argue that flexible and adaptable process modelling may help to assure the flexibility and the adaptability of the BP. Since organisation settings and users objectives and viewpoints are divergent and even conflicting, a single BP formalism is still insufficient. A promising idea is to propose an approach for adapting and configuring existing formalisms according the organisation settings and users objectives, rather than to advice for a single one which can be of high quality for specific requirements and inadequate for others. The formalisms can be described by meta-modelling. The meta-model allows defining the process model and its concepts (e.g. activity, role). It corresponds to the level 2 of the OMG four-level-architecture for the processes [2]. The process model instantiates the meta-model in order to represent a process. An instance represents an actual BP. Thus, we focus on the flexibility at the BP meta-model level.
BPs are of various kinds and are defined in different levels of abstraction using various artefacts depending on the organisation settings and the purpose of the modelling. For instance, in mechanistic or production organisations, BPs are often prescribed in a very detailed level since they shall be executed. On contrary, in adhocracies organisation, more freedom can be left to business actors for choosing how to perform the underlying business objectives. Accordingly, since formalisms are proposed for various purposes, none of them captures all the mentioned aspects. They may be dissimilar and based on different techniques. While activity-oriented approaches [2] focus on executability by software tools and translation into executable languages such as BPEL4WS or ebXML, intention-oriented approaches aim to capture business goals, human reasoning, decision making, and interaction between actors [22], [21], [23], [39], [40].
Nonetheless, even if these formalisms capture different views of the business, sometimes their interrelationships could or should be taken into consideration and their complementarity needs to be expressed. That is, in some situations, activityoriented and product-oriented approaches need to be matched in order to determine which activity influences on which product and on which step of the process. Also, strategy-oriented meta-models require to be made operational using activity-oriented models [21]. As well, [37] combines intention-oriented and state-based process modelling. One can say that there is need of a comprehensive formalism that captures all mentioned aspects. Nevertheless, as mentioned, these requirements are often situation-aware and not universal. Each aspect may or may not be relevant for a given organisation and a particular situation. In other words, according to usage conditions, some aspects have to be captured in a process meta-model and not the others. What is required in not an exhaustive meta-model, but mechanisms for adapting existing ones to specific requirements. Note that none of existing formalisms offer extension or adaptation mechanisms. Our aim in this paper is to propose the study of such mechanisms. We will not compare process meta-models neither to recommend particular ones. These issues have been dealt with in many studies (See for instance [32], [36]). Our motivation behind this proposal is that a formalism which is used for modelling BP in a specific organisation setting is not necessarily adequate for others; and since several formalisms have proved their effectiveness in many business areas, it does not seem necessary to develop new ones.
In the community of information systems development (ISD), the field of method engineering (ME) has been introduced as a response to the need for methods adapted to specific ISD project situations, and to the failure of the methods known as "universal" [29]. One area of ME, is the Situational Method Engineering (SME), which aims to construct new methods and the associated tools or to adapt existing ones to every ISD project [13]. We highlight that the ISD requirements on flexibility and adaptability that are behind the ME emergence in the ISD field are similar to those currently observed in the BPM field. We will thus base our reasoning on SME mechanisms. The reminder of the paper is structured as follows. Section 2 presents background and discusses related works. Section 3 introduces our approach with an illustrative example. Section 4 concludes the paper.
BP modelling consists in capturing processes and highlighting significant organisational and operational aspects of the business. It may serve two distinct purposes: descriptive or prescriptive [4], [14]. The descriptive perspective aims at recording and providing a trace of what happens during the development process (see for example [7], [27]. The prescriptive perspective is used to describe "how things must/should/could be done" and is often used as ways-of-working [35]. BPs can be roughly classified into two categories depending on their nature. The first one concerns well-defined and -often-repetitive processes having important coordination and automation needs. The second one concerns ill-defined processes. For many organisations, well-defined and ill-defined processes coexist and must be handled in the final BP model [20].
There exists a number of process modelling formalisms, e.g. activity-oriented modelling (like [15], [12]. They focus on the activities and their ordering. Productoriented process approaches combine the product state with the activity generating this product state (e.g. statecharts [9] and the state-transition diagram (state machines) [17]). A product-oriented model defines the manner a product translates from one state to another, i.e. by what transition. The more recent approaches for process modelling are goal-oriented [19], decision-oriented [21], and intention-oriented [31]. They capture the Why in addition the What and How issues.
Method engineering (ME) is the discipline to study engineering techniques for constructing, assessing, evaluating and managing tools for developing ISD Methods [30]. Situational method engineering (SME) promotes the construction of a method by assembling reusable method chunks stored in some method base [26]. The method elements are often represented using meta-modelling approaches. For details about SME related research, refer for instance to [5], [10], [16]. There exist four well-known principles of ME which are: meta modelling, flexibility, reuse and modularity [30]. [18] introduces a faceted framework to understand and classify issues in system development SME.
The context plays an important role in several disciplines like natural language semantics and artificial intelligence knowledge management, and web systems engineering [1], [3]. In the domain of BP modelling, context awareness is relatively new field of research. However, some papers on this subject have already been published [32], [34]. In this paper, we mean by the context the knowledge which captures the situation of use of the chunk.
We argue that a BP may be considered according different points of views and different abstraction levels according to the situation at hand and the decision-maker vision. Building the adequate meta-model can be done following several manners, for instance, (i) by assembling relevant concepts, which belong to different meta-models, (ii) by constructing a core meta-model and enhancing it with required concepts, (iii) by choosing one basic meta-model from the existing ones, and extending it, if necessary, with the appropriate concepts, (iv) by choosing a meta-model that captures most relevant aspects (for instance activity and product related aspects), and adapting it by deleting and/or adding concepts. With analogy to the method in the ISD field, we introduce the concept of business method which consists on a set of reusable components that we name business chunks. A business method is composed of a product model and a process model; in this paper we consider only the product model. In the reminder, we denote by chunk a business chunk. Chunks are stored in a chunk repository in order to enable operations of research, comparison and extraction on them. They can be reused and combined in order to build new chunks or extending or adapting existing ones. A chunk can be simple or composed of other chunks. In the reminder, we formally define chunks and as well as some functions which are relevant for building chunks. We are inspired from some operators defined in [5] and [25]. Our belief is that instead of defining a complete set of features in a single metamodel, a taxonomy of independent features can be defined and captured into various chunks depending on the situation. Thus, in a given situation, the process engineer can select or build the appropriate meta-model.
We define a chunk ch i as followed: ch i = (id_ch i , pm i , c i , a i ), where id_ch i is the identifier of the chunk ch i , pm i is the product meta-model of ch i , c i is the context of use of ch i , i.e. in which situation ch i can be used. a i is an annotation describing it. E is a finite set of elements, E = {e 1 , e 2 … e n }. R is a finite set of relationships between the elements, R = {r 1 , r 2 … r m }, where r i =(name_r i , type_r i , e j , e k ), type_r i ∈{"association", "aggregation", "inheritance"}. P is a finite set of properties, P={p 1 , p 2 , …, p n }, where p i =(name_p i , e j , domain). PM is the set of product models, PM ⊆ ExRxP.
We define the following functions: pm:
is a function mapping each chunk ch i to the set of the elements of ch i , where
is a function mapping each chunk ch i to the set of relationships of. ch i , where
2 → is a function mapping each element e i to the set of properties of e i , where ) (P card l = .
Formulas (1), ( 2), ( 3) and ( 4) present some functions which allow respectively (i) to add an element to an existing chunk, (ii) to add a relationship between two elements that belong to two different chunks, (iii) to add a property to an element, and (iv) to rename an element. In fact, in some cases, even if two concepts of different models are semantically similar, they are named differently. For instance, the concepts of task in BPMN, stage in VPL [38] and activity in ICN [6] have the same semantic. As well as the concepts of procedure [6] and plan [38]; and business intention and business goal (see Fig 1).
Illustrative example. Let us consider two chunks ch1 and ch2 (see Fig 1).
) represents the meta-model of the intentional view of the BP modelling framework defined in [22], [23]. According to Nurcan et al., business maps aim to provide an intention/decision-oriented definition of BPs [23]. The intentional view is based on the map model defined by Rolland et al. [31]. We will briefly recall the map model. A map is a labelled directed graph with intentions as nodes and strategies as edges between intentions. It consists of a number of sections each of which is a triplet <source intention Ii, target intention Ij, strategy Sij>. An intention is defined as a goal that can be achieved by the performance of a process. A strategy is defined as a manner to achieve an intention. A map has associated guidelines for the selection of the next intentions and strategies on the one hand as well as for the achievement of the selected strategies on the other hand. Guidelines take into consideration the situation at hand. According to Nurcan et al., business intention and strategy selection guidelines describe the know-how of the business decisional level [23].
Fig. 2 (Ch 2 ) represents the meta-model of a role-based BP modelling approach which is based on and keeps a minimal set of features of the approach proposed in [33]. The purpose of the latter [33] was to overcome the limitations of the classical techniques by providing a set of extension mechanisms around the concept of role. In Ch2, organizations are structured as networks of BPs in order to achieve their business goals. BPs can be first analysed in terms of roles played by actors. Each actor belongs to one or more organisational units and is assigned to appropriate roles based on his/her responsibilities and qualifications. An actor represents a human being or autonomous agents. The central concept of Ch2 is the role. A role is a semantic construct about which business rules and other concepts can be formulated.
It can represent a competency to realise particular functions, e.g. "engineer", and can embody authority and responsibility, e.g. "project supervisor". Each actor belongs to at least one organisational unit and is assigned to appropriate roles based on his/her responsibilities and qualifications. A business goal is reached by performing one or more BPs. Ch2 can be suitable to stable organisations where changes are minor. For more details see [33].
In order to make ch 1 executable, we need to assemble the two chunks, to do this, we can use the function add_element (ch2, BP fragment, includes) (formula (1)) in order to add a new element BP fragment and the relationship includes between the elements Business process (of ch2) and BP fragment in order to make operational a section following the associated intention achievement guideline. Next, we use the function add_relationship (ch1,ch2, Intention_Achievement_Guideline, BP fragment, Makes-operational) (formula (2)) in order to create the relationship Makes-
This paper provides a start point towards an approach for configuring and adapting meta-models for BP modelling that are customised to the situation at hand. We have introduced the concepts of business method and business chunk. The proposed approach allows capturing in the meta-model different aspects of business processes and defining relationships between them by using business chunks. We promote the idea that the final meta-model has to be created from the set of proposed chunks in order to suit to a particular organisation setting. This approach aims to make easier the definition of flexible customised meta-models.
The work presented in this paper is the first attempt for the situational process meta-modelling for flexible BPs. Dealing with situation-awareness raises many questions which need further research such as the contexts influencing the selection of the adequate chunks, the definition of a comprehensive set of assembly, adaptation and extending functions, the description of the process of meta-model building, the definition of rules for extending meta-models.