Context-based Conﬁguration of Process Variants

Alena Hallerbach

, Thomas Bauer

and Manfred Reichert

Group Research and Advanced Engineering, Daimler AG, Ulm, Germany

Institute of Databases and Information Systems, Ulm University, Germany

Abstract. When designing process-aware information systems, usually, variants

of the same process type have to be deﬁned and maintained. Each of these process

variants constitutes an adjustment of the same process to speciﬁc requirements

building the variant context. Current business process management tools do not

support the context-based deﬁnition and conﬁguration of such variants in an ade-

quate manner. Instead, each process variant has to be deﬁned from scratch and be

kept in a separate model. This results in considerable redundancies when model-

ing and adapting process variants, and is also a time consuming and error-prone

procedure. This paper presents a more ﬂexible and context-based approach for

conﬁguring and managing process variants. In particular, we allow for the con-

ﬁguration of process variants by applying a context-dependent set of well-deﬁned

change operations to a base process.

1 Introduction

The ﬂow of activities which have to be performed to achieve speciﬁc goals is often

captured in a process model. Usually, each model implements a particular process type

(e.g., handling a credit request or travel cost refund) by describing process activities,

execution constraints, required resources (e.g., humans or IT systems), and informa-

tion processed. There exists a variety of tools like ARIS Business Architect [1], ADO-

NIS [2], or WebSphere Business Modeler [3] for creating and managing such process

models. Typically, respective process modeling tools are used to improve process trans-

parency, to optimize a process, or to implement a process-aware information system,

e.g., based on a Workﬂow Management System (WfMS) [4,5].

Process support is required in almost all business domains (e.g., healthcare [6],

engineering [7], or public administration). Characteristic process examples from the

automotive domain, for example, include product creation, product change manage-

ment, and release management [7]. In practice, different variants of a particular process

type are usually required. Figure 1 a, for example, depicts a simpliﬁed product change

process that starts with initiating a change request (Activity 1). Afterwards comments

(cmts.) are requested from those departments that might be affected by the change (Ac-

tivities 2a, 2b, and 2c). After all comments have been received an integrated change

document is created (Activity 3). This document is then passed to the decision board

which either approves the requested change or rejects it (Activity 4). In case of approval,

the development department implements the change (Activity 5). Otherwise this step is

skipped.

Hallerbach A., Bauer T. and Reichert M. (2008).

Context-based Conﬁguration of Process Variants.

In Joint Proceedings of the 5th International Workshop on Ubiquitous Computing (IWUC 2008) 4th International Workshop on Model-Driven Enterprise

Information Systems (MDEIS 2008) 3rd International Workshop on Technologies for Context-Aware Business Process Management (TCoB 2008),

pages 31-40

DOI: 10.5220/0001729600310040

 SciTePress

Fig.1. Variants of a Standardized Product Change Process.

Different variants of this process exist in practice: Variant 1 (cf. Figure 1 b) treats

quality critical changes in a special way; i.e., the quality department is involved in the

commenting process. At the model level this behavior can be realized by inserting an

additional activity (Activity 2d) into the original process. Figure 1 c shows Variant 2

for which the change request is shortened. Particularly for changes with low implemen-

tation costs the development department often starts implementing the change without

waiting for its approval. If the decision board rejects the request, change implementa-

tion will be undone later. This variant can be realized by moving Activity 5 to a position

parallel to the commenting activities and by conditionally inserting the Undo activity

(Activity 6). Finally, Variant 3 (cf. Figure 1 d) will be required if the change affects

quality critical issues and can be shortened as well. This variant constitutes the com-

bination of Variant 1 and 2. Thus, the process inherits all adjustments from these two

variants; i.e., an additional comment is requested from the quality department and early

implementation of the change becomes possible.

In practice, additional variants are required, e.g., satisfying speciﬁc constraints of

the respective vehicle project or development phase. In existing approaches such pro-

cess variants have to be deﬁned and maintained in separate process models similar to

those of Figure 1. This results in a large amount of redundant model data as the vari-

ant models are identical or similar for the most part. Considering the large number of

variants required in practice, this drawback increases modeling and maintenance ef-

forts signiﬁcantly. This is both time-consuming and error-prone. Unfortunately, current

business process management tools do not allow for the context-based deﬁnition and

conﬁguration of a process variant that captures a given situation best.

This paper introduces the Provop (PROcess Variants by OPtions) approach. In par-

ticular, it provides an advanced solution for modeling process variants starting with a

common process model and using an operational modeling approach. Provop allows

for the context-based conﬁguration of process variants, as discussed in detail in this

paper, and enables full life cycle support [8]. The remainder of this paper is structured

as follows: In Section 2 we introduce basic concepts of the Provop approach. Section

3 presents the conﬁguration of process variants using context rules. Section 4 discusses

related work. The paper concludes with a summary and an outlook in Section 5.

2 Basic Concepts of Provop

Our Provop approach has been motivated by the fact that a process variant can be typi-

cally created by “cloning” a given process model and by adjusting it to a given context.

In Provop we adapt this method to base the different variants of a particular process

type on a single

base process

. This base process can be a standard process or espe-

cially created for variant deﬁnition [9]. The variant-speciﬁc adjustments of the base

process are expressed in terms of high-level

change operations

. Provop itself allows to

INSERT

DELETE

, and

MOVE

process fragments

. Furthermore, a

MODIFY

operation for

changing attributes (e.g., actor assignment, activity durations) is provided. To allow for

more complex process adjustments, change operations can be grouped into reusable

sets, which we denote as

options

. Thus a particular process variant is conﬁgured by ap-

plying one or more options to the respective base process, i.e., by performing all change

operations set out by these options [9].

Figure 2 illustrates the basic concepts of our approach taking the example of a pro-

duct change process from Figure 1 (for the sake of readability we have reduced activity

names to logically corresponding numbers): The process model depicted in Figure 1 a

is considered as the base process from which all variants shall be derived (cf. Fig-

ure 2 a). The difference between Variant 1 (cf. Figure 1 b) and the base process can

be described by an option (i.e., Option 1). This option comprises an

INSERT

opera-

tion that adds Activity 2d to the base process. The

INSERT

operation requires the exact

position for inserting Activity 2d. Therefore we deﬁne

adjustment points

which are

used to connect the incoming and outgoing edges of the new fragment with the base

process

. By applying Option 1, i.e., by inserting Activity 2d between the adjustment

points “start-comments” and “end-comments”, the process model named Variant 1 can

be created (cf. Figure 2 c). To conﬁgure the model of Variant 2 (cf. Figure 1 c) we

deﬁne Option 2 which consists of the following change operations: The ﬁrst operation

constitutes an insertion of the undo activity (Activity 6) between the adjustment points

A process fragment is a sub-graph with at least one process element (e.g., node or edge).

Note that adjustment points are placed at the entry or exit of a node in the base process and are

used by a change operation as reference.

“rejected” and “rejection complete” from the base process. The second operation per-

forms a

MOVE

of Activity 5 from its original position (given by the adjustment points

“start-implementation” and “end-implementation” in the base process) to its new posi-

tion between “start-comments” and “decision”. The resulting process model is depicted

in Figure 2 c.

Fig.2. Options and Process Variants in Provop.

A main advantage of this operational modeling approach is the ability to conﬁgure

new process variants without additional modeling efforts. More precisely, when apply-

ing both options conjointly and therefore performing all change operations deﬁned by

them the process model of Variant 3 (cf. Figure 1 d) results.

3 Conﬁguring Process Variants based on Context Rules

Basic to variant conﬁguration in Provop is the controlled usage of change operations

grouped as reusable sets (i.e., options). By selecting respective options and by applying

them to a given base process the desired variant can be deﬁned. Typically, particular

process variants are required in a speciﬁc context. Therefore, Provop considers context-

based variant conﬁguration as a crucial concept. In Section 3.1 we motivate the need

for context-awareness and describe the resulting requirements for our approach. Sec-

tions 3.2 - 3.4 explain how these requirements are met.

3.1 Use Cases and Requirements

The product change management process as depicted in Figure 1 a can be considered as

“standard” process that is used to derive different variants (cf. Figures 1 b - 1 d). Each

variant then corresponds to a use case that occurs in a given context. This context is

provided by the attributes of the change request, which indicate, for example, whether

the change is relevant for product quality, what the expected implementation costs are,

and which product components are affected by the change. This can be expressed in

terms of context variables, each with a given value range; e.g., the context variable

Implementation Costs

has one of the values “low”, “medium”, or “high”. Gener-

ally, each context variable deﬁnes one dimension of the process context which might be

relevant for variant conﬁguration. Consequently, multiple context variables correspond

to a multidimensional cube. For example, the context of the product change process is

given by the

context cube

depicted in Figure 3 (simpliﬁed view): The axes are corre-

sponding to the context variables

Quality Relevance

Implementation Costs

, and

Phase

. When specifying the values for all context variables or a subset of them we

obtain a particular process context, which logically corresponds to a

sub-cube

within

the context cube. Simply speaking, each process variant is linked to a sub-cube which

describes its valid context (cf. Figure 3).

Fig.3. Context Cube of Possible Context Descriptions.

To allow for context-based variant conﬁguration several requirements have to be met

[10]:

Req. 1 (User-friendly Deﬁnition of Context). A key prerequisite concerns the deﬁni-

tion and maintenance of a process context model. To obtain optimal support, an intuitive

method is required to support these tasks.

Req. 2 (Deﬁnition of Valid and Invalid Value Combinations). A particular sub-cube

of the context cube might not be valid. This will be the case, for example, if the combi-

nation of certain context values for a given set of variables does not make sense. Con-

sequently, no consistent process variant is required in this context. All valid sub-cubes,

in turn, require a consistent and correct variant assignment. In some way all “valid”

sub-cubes must be identiﬁed and captured within the context model.

Req. 3 (Context-based Selection of Options). To allow for the context-based conﬁg-

uration of variants, options (i.e., collections of change operations) and context descrip-

tions have to be linked. Thereby, it must be deﬁned, which option(s) shall be used in a

particular context (i.e., sub-cube). As Provop aims at modularity and reuse, single op-

tions should be applicable in different context; i.e., it must be possible to assign them to

several sub-cubes. A process designer must further be able to design a particular variant

by setting the respective context.

Req. 4 (Context Changes During Runtime). The values of context variables may

change during process execution. Thus the currently selected process variant might be-

come obsolete and might have to be replaced by another one; i.e., other options have to

be chosen and applied to conﬁgure the desired process. If such a context change occurs

during runtime (i.e., while process instances of the variant to be replaced are executed in

a WfMS), reconﬁguration of the running process instances has to be supported. Such a

reconﬁguration may apply additional options to the base process and undo adjustments

of obsolete options as well.

In the following we describe in detail how Provop deals with these requirements.

3.2 Process Context Deﬁnition

To allow for the context-based conﬁguration of a process variant, ﬁrst of all, a model for

capturing the process context is needed (cf. Req. 1). In Provop, such a model comprises

a set of

context variables

. Each context variable represents one speciﬁc dimension of

the process context, and is deﬁned by a name, a variable description, and a value range.

In Provop we capture this context information in a table (cf. Figure 4). This allows

the context modeler to create new entries and to manage existing ones in a simple and

intuitive way.

Fig.4. Example of a Context Deﬁnition in Provop.

The context variables shown in Figure 4 do not only differ in their names and val-

ues, but also in another important aspect. While some context variables are static (e.g.,

Vehicle Project

) others are dynamic. For example, the context variable

Phase

has

dynamic nature since it is updated after a development phase is completed (e.g., switch-

ing from “start-up” to “production”). This information is relevant, for example, to de-

cide whether an option that is chosen based on a certain value of a context variable is

ultimately deﬁned or whether it may become obsolete during process execution. There-

fore Provop captures the

mode

of a context variable as well (cf. Table 4).

Based on our experience there exist valid and invalid combinations regarding the

values of the different context variables (cf. Req. 2). One simpliﬁed example that is

highly relevant in practice is as follows: Due to its “very high”

Quality Relevance

a requested product change necessitates extended validation and veriﬁcation actions,

which leads to additional expenses. Consequently, setting the value of the context vari-

able

Implementation Costs

to “low” at the same time is not a valid combination in

practice. For each valid value combination, in turn, it must be ensured that a consistent

and correct process model exists for the required variant. Therefore the consideration of

such value interdependencies is crucial. Referring to the context cube depicted in Fig-

ure 3 a, a classiﬁcation of valid and invalid combinations (i.e., sub-cubes) would lead

to high efforts when considering the number of possible context variables in practice

(typically about 10 to 20 variables) and their respective value ranges. In such scenarios

a context cube is no longer sufﬁcient. Simple constraints, for example, the value of one

context variable directly implies the value of another one (e.g., a

Vehicle Project

is always in exactly one

Phase

), can be modeled as a dependency graph like the one

depicted in Figure 5 b. To be able to handle more complex dependencies, e.g., between

multiple variables, Provop offers a rule-based logic (cf. Figure 5 c) in addition. All de-

pendencies (i.e., simple and complex ones) are graphically illustrated in an overview on

context variable level as depicted in Figure 5 a. By doing so, a user-friendly deﬁnition

of complex context constraints with sufﬁcient graphical support is realized.

Fig.5. a) Dependencies between Context Variables (Overview), b) Dependency Graph, and c)

Dependency Rules.

3.3 Context Rules

Provop follows an operational approach for variant modeling. Therefore, a direct map-

ping of already conﬁgured variants to a context description is not feasible. Instead,

for conﬁguring a process variant in a particular context, the relevant options must be

selected based on the contextual knowledge (cf. Req. 3). In Provop this relationship

between options and context values is realized by so called

context rules

. Regarding the

current context all options whose context rules evaluate to “true” are applied to the base

process and therefore determine the required variant. As a special case, the base process

itself may be used as one particular process variant (i.e., no option is applied).

Figure 6 shows an example: Option 1 will be applied if a product change is of

“high”

Quality Relevance

. Option 2, in turn, will be applied if the product change is

requested for the

Vehicle Project

“Hybrid car”. For example, when evaluating the

current context as speciﬁed by “high”

Quality Relevance

, “low”

Implementation

Costs

, and the

Vehicle Project

“Current C-Class”, only the context rule assigned to

Option 1 evaluates to “true”. As a consequence, Option 1 is applied to the base process

creating the process model of the variant depicted in Figure 6 b.

Fig.6. a) Context Rules assigned to Options and b) the Resulting Process Variant.

3.4 Context-based Reconﬁguration of a Process Variant at Runtime

To capture context changes during process instance execution, Provop allows for the

usage of dynamic context variables, whose values may change during process execu-

tion.

If dynamic context variables are used for deﬁning a context rule of an option,

the decision whether to apply the corresponding change operations or not has to be

made at runtime (cf. Req.4). As a consequence, the respective process variant either

cannot be completely conﬁgured when creating the process instance or has to be re-

conﬁgured during runtime. To allow for the conﬁguration of a complete (and therefore

executable) process instance of a variant, Provop uses

variant branches

in its process

models. The basic idea is to encapsulate the adjustments of single options within these

variant branches. The split condition at the variant branch corresponds to the context

rule of the option. Whenever process execution reaches a variant branch, the current

context is evaluated. If the split condition evaluates to “true” the variant branch is exe-

cuted, i.e., the change operations are applied to the base process. Otherwise, the variant

branch is skipped and therefore all adjustments of the option are ignored.

Figure 7 a shows an example of a variant branch deﬁnition: As the application of

Option 1 depends on the dynamic context variable

Phase

the corresponding process

fragment is encapsulated in a variant branch (indicated by the encircled “less than” and

“greater than” symbols). Furthermore, the context rule of Option 1 is used as a split

condition during process execution. If it evaluates to “true” (cf. Figure 7 b) the variant

branch will be executed, otherwise it will be skipped (cf. Figure 7 c).

Fig.7. Context Change during Runtime.

A change update of a dynamic context variable at runtime may affect variant bran-

ches that are (partially) ﬁnished. Thus, if an evaluation result of a split condition be-

comes invalid a reconﬁguration of the process will be required. In Figure 7 d, the prod-

uct change process was started during the

Phase

“start-up”. Consequently the variant

branch of Option 1 was activated. During the execution of this variant branch a context

change occurs for the dynamic context variable

Phase

, which is set to “production”.

Therefore, the context rule assigned to Option 1 evaluates to “false”. As a consequence

the execution of the corresponding variant branch must be rolled back by an abort re-

spective undo of the Activities N2 respective N1.

Static variables are deﬁned at process instance creation and cannot change during runtime.

Since a rollback of completed activities is accompanied by the loss of work it is

not always feasible. Therefore the behavior is controlled by a steering parameter. It

indicates that rollbacks i) are always enabled, or ii) are always disabled, or iii) always

require a decision of the process administrator whether or not they are performed.

4 Related Work

The context of an actor or a software system can be utilized to realize context-aware

applications in different domains (e.g., healthcare [11] or learning solutions [12]). Such

applications gather contextual information about a user or system and adapt their behav-

ior accordingly. For example, in mobile computing context-aware applications might

use information about the location of a user as well as the output device to provide

context-speciﬁc services and to visualize information in an adequate way [13, 14].

Process management is concerned with context related aspects as well. For exam-

ple, the context of a speciﬁc process task can be used to display data, information and

knowledge relevant to perform this task.

In [15] a bottom-up approach for the (semi-)automatic conﬁguration of project-

speciﬁc process models is presented. Respective processes are created by combining

generic process building blocks, taking into consideration project-speciﬁc context (e.g.,

expressed in terms of requirements that inﬂuence the process conﬁguration). This ap-

proach requires a complete and therefore also extensive rule set to build consistent and

executable processes out of process building blocks.

A top-down approach for process model conﬁguration is described in [16]. Refer-

ence process models are represented using conﬁgurable Event-Process-Chains (c-EPC)

[17]. Generally, such a reference process model is of recommending character and can

be customized in different ways to meet speciﬁc needs. Therefore, a reference process

model represents all possible control ﬂow alternatives. Using a questionnaire that com-

prises questions expressed in natural language, conﬁguration facts are gathered. These

facts are evaluated at variation points within the reference process model to conﬁgure a

speciﬁc model by either executing, skipping or optionally skipping a process element.

As one drawback this approach only allows for the conﬁguration of single elements at

given points in the process model (i.e., it is not possible to mark a complete branch

as mandatory or optional). It is also not possible to move or add model elements or to

adept element attributes like we do in Provop. As compared to reference process mod-

els, the basic process in Provop can be modeled without any restriction; i.e., it needs

not to be deﬁned with a speciﬁc use case in mind nor it constitutes a recommendation

for all processes of a given type.

5 Conclusions

We have described the Provop approach for conﬁguring context-based process variants:

Context variables, context values and context constraints (e.g., valid value combina-

tions) are deﬁned in a user-friendly manner. The options used for a process variant are

selected when evaluating context rules. This enables a process variant conﬁguration

based on the current context. In addition, Provop allows reacting to context changes

during runtime by late evaluation of split conditions of variant branches or the recon-

ﬁguration of running process variants. The need of the presented concepts and related

requirements have been elicited in a number of case studies we conducted in the auto-

motive domain; i.e., practical relevance of Provop is high.

In future work we will detail the Provop approach: We will address the conﬁgura-

tion of consistent process variants, when multiple options are required in the speciﬁed

context. Sophisticated techniques are required to prevent errors and consistency prob-

lems (e.g., deadlocks, data ﬂow inconsistency) due to conﬂicting change operations.

Finally, a detailed validation study of our concept based on a prototype that implements

the Provop concept will be conducted.

References

1. IDS Scheer: ARIS Platform Method 7.0. (2006)

2. BOC: The Business Process Management Tool ADONIS. (2007) (in German).

3. IBM: IBM WebSphere Business Modeller, Version 6.1. (2007)

4. Dumas, M., van der Aalst, W., ter Hofstede, A.: Process-aware Information Systems. Wiley,

Los Angeles, CA (2005)

5. Weske, M.: Business Process Management - Concepts, Languages, Architectures. Springer

(2007)

6. Lenz, R., Reichert, M.: IT Support for Healthcare Processes - Premises, Challenges, Per-

spectives. Data and Knowledge Engineering 61 (2007) 39–58

7. M¨uller, D., Herbst, J., Hammori, M., Reichert, M.: IT Support for Release Management

Processes in the Automotive Industry. In: Proc. of the 4th Int. Conf. on Business Process

Management. (2006) 368–377

8. Hallerbach, A., Bauer, T., Reichert, M.: Managing Process Variants in the Process Life

Cycle. In: Proc. of the 10th Int. Conf. on Enterprise Information Systems. (2008)

9. Hallerbach, A., Bauer, T., Reichert, M.: Modelation and Visualization of Process Variants

in Provop. In: Proc. of Modellierung, Berlin (2008) (in German).

10. Hallerbach, A., Bauer, T., Reichert, M.: Requirements for Modelation and Visualization of

Process Variants. In: Datenbank Spektrum. (2008) (in German).

11. Bricon-Souf, N., Newman, C.: Context-awareness in Healthcare: A Review. In: International

Journal of Medical Informatics. Number 76. Elsevier (2007) 2–12

12. Schmidt, A.: Potentials and Challenges of Context-awarness for Learning Solutions. In:

Proc. 13th Annual Workshop of the SIG Adaptivity and User Modeling in Interactive Sys-

tems. (2005)

13. Schilit, B., Theimer, M., Welch, B.: Customizing Mobile Applications. In: Proc. of the

Symp. on Mobile and Location-independent Computing, Cambridge, MA (1993) 129–138

14. Schilit, B., Adams, N., Want, R.: Context-aware Computing Applications. In: Proc. Work-

shop on Mobile Computing Systems and Applications. (1994) 85–90

15. Rupprecht, C., Rose, T., van Halm, E., Zwegers, A.: Project-speciﬁc Process Conﬁguration in

Virtual Enterprises. In: Proc. of the 4th Int. Conf. on the Design of Information Infrastructure

Systems for Manufacturing, Deventer, The Netherlands (2000) 46–53

16. Rosa, M.L., Lux, J., Seidel, S., Dumas, M., ter Hofstede, A.: Questionnaire-driven Conﬁgu-

ration of Reference Process Models. In: Proc. of the 19th Int. Conf. on Advanced Information

Systems Engineering. (2007)

17. Rosemann, M., van der Aalst, W.: A Conﬁgurable Reference Modelling Lanugage. Infor-

mation Systems 32 (2007) 1–23