Keywords

These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

1 Introduction and Motivation

“The story of the practical use of [b]usiness [p]rocess [m]anagement in different organizations is one of diversity and of effective outcomes” (Armistead et al. 1999). This statement highlights the fact that there is no “one-size-fits-all” approach to Business Process Management (BPM). Many academic authors argue that the progress toward organizational excellence through process-oriented management takes place in different stages, that different approaches or aspects thereof are pre-dominant at different levels of organizational development, and that almost each and every organization has developed its own approach to BPM (Ho and Fung 1994; Armistead et al. 1999; Balzarova et al. 2004). Moreover, there is also evidence from corporate practice that real-world organizations adopt BPM in many different ways. However, research is scarce, which is explicitly directed at gaining insight into and understanding the nature of these situational aspects of BPM, or which aims at identifying, categorizing, and describing different BPM approaches.Footnote 1

During the last 2 decades, a huge amount of methods to support BPM or particular stages thereof have been proposed. Two popular examples are methods for business process modeling (cf. e.g., Scholz-Reiter et al. 1999; List and Korherr 2006) and methods to support business process reengineering (cf. e.g., Davenport and Short 1990; Hammer 1990; Harrington 1991; Kaplan and Murdock 1991; Davenport 1993; Hammer and Champy 1993; Hammer and Stanton 1995; Harrington 1995; Imai and Heymans 1999). These proposals, however, are more or less generic, that is, they are aimed at supporting BPM or particular aspects thereof without taking into account situational aspects. Implicitly or even explicitly, almost universal validity is claimed.

In order to close this gap and to support the engineering of situation-specific methods, this chapter proposes taxonomy of BPM approaches. This taxonomy represents an essential basis for the situation-specific adaptation of generic methods and/or for the construction of new situational methods to support BPM within real-world organizations. Furthermore, the chapter is aimed at contributing to the current discussion about BPM maturity models (cf. e.g., DeToro and McCabe 1997; Pritchard and Armistead 1999; Maull et al. 2003; Rosemann and de Bruin 2005; Harmon 2006; de Bruin 2007; Hammer 2007).

The remainder of this chapter is structured as follows: Section 2 provides a detailed introduction to the principles of method construction and situational adaptation. Section 3 reports on empirical results of research targeted at the identification and systematization of BPM approaches as a basis for the engineering of situation-specific methods. These findings are largely on the basis of our previous work (Bucher and Winter 2006, 2008). Section 4 demonstrates the applicability of those results by sketching situation-specific embodiments of Davenport’s method for process redesign (Davenport and Short 1990; Davenport 1993). Section 5 summarizes the main findings and provides an outlook on further research.

2 Situational Method Engineering

This section is intended to familiarize the reader with the basic principles of method construction and situational adaptation. To this end, we first introduce design research for information systems as the fundamental research paradigm and outline the basics of method engineering. Two aspects of particular interest, namely the representation of situational characteristics as well as the definition of fragments as the essential building blocks of situational methods, are then discussed in detail.

2.1 Design Research for Information Systems

The design research (DR) paradigm for information systems (IS) development has been discussed intensively in recent years. As opposed to behavioral research, DR for IS is not primarily aimed at discovering and justifying theories but rather at creating solutions to specific problems of practical relevance (March and Smith 1995; Hevner et al. 2004). Both design processes and design products play an important role in DR: “As a product, a design is ‘a plan of something to be done or produced’; as a process, to design is ‘to so plan and proportion the parts of a machine or structure that all requirements will be satisfied’” (Walls et al. 1992).

As for the process aspect, the current body of DR literature proposes a variety of IS research processes that are closely related to each other (cf. e.g., March and Smith 1995; Hevner et al. 2004). Niehaves (2006) summarizes these proposals and suggests the IS research cycle depicted in Fig. 1.

Fig. 1
figure 1

IS research cycle. Adapted from Niehaves (2006)

Full size image

The outcome of the design process – the design product – is commonly referred to as “artifact,” i.e., as human-made object of any kind (Simon 1996). In the context of DR for IS, artifacts are typically of four types, namely constructs, models, methods, and instantiations (Nunamaker et al. 1990; March and Smith 1995; Hevner et al. 2004). In the following, we will concentrate on methods as one particular type of DR artifacts. A method is “an approach to perform a systems development project, based on a specific way of thinking, consisting of directions and rules, structured in a systematic way in development activities with corresponding development products” (Brinkkemper 1996).

The discipline concerned with the design, construction, adaptation, and evaluation of methods is referred to as “method engineering” (ME). Most research in the field of ME originates from software engineering. For that reason, a lot of ME publications exhibit more or less explicit references to the domain of software engineering. In this chapter, we will argue that most of the underlying principles of ME can be applied to the business domain – namely Business Process Management – as well. The primary design object of the business domain is the so-called “IT-reliant work systems” (Alter 2003, 2006). A work system (WS) is defined as a “system in which human participants and/or machines perform work using information, technology, and other resources to produce products and/or services for internal or external customers” (Alter 2003). Consequently, methods pertaining to the business domain are targeted at the engineering and/or change of a WS.

In order to be applicable for IS development, methods need to be adapted to the specific characteristics of the so-called development situation or application situation. This approach is commonly referred to as “situational method engineering” (SME) (Kumar and Welke 1992; Harmsen et al. 1994; van Slooten and Hodes 1996; Harmsen 1997) and may be ascribed to the so-called “contingency model” proposed by Fiedler (1964). According to this scientific theory, there is no “best way” of organizing or leading an organization. On the contrary, there are various internal and external factors that influence organizational effectiveness, and therefore the organizational style must be contingent upon those factors.

2.2 Representation of Situational Aspects in SME

Methods are aimed at the engineering and/or change of WS. In the following, we will refer to engineering/change of a WS as “transformation.” Consequentially, a method represents a systematic means for the transformation of a WS from an initial state (IS) to a target state (TS) (cf. Fig. 2). The part (i.e., the set of system elements) of a WS that is transformed by the application of the method is denoted as WSPT. The tuple of initial state of WSPT, denoted as PTIS, and target state of WSPT, denoted as PTTS, is referred to as “project type” (Bucher et al. 2007). However, as a matter of fact, each WSPT is part of a larger WS. All system elements that are not transformed by the application of the method (i.e., that are not part of WSPT) but that are part of the WS under consideration are referred to as environmental work system WSCT. The initial state CTIS of WSCT does not differ from its target state CTTS. Although WSCT is outside of the method’s transformation scope, the state of its system elements (CTIS = CTTS, in the following denoted as “context type” (Bucher et al. 2007)) may influence the applicability, effectiveness, and efficiency of the method.

Fig. 2
figure 2

Method-based transformation of work systems. Bucher and Klesse (2006), Bucher et al. (2007)

Full size image

Context type (CT) therefore comprises all factors that do influence the IS development process but that themselves are not changed by the application of the method. In contrast to that, project type (PT) comprises all aspects of an IS development project that both influence the IS development process and that are at the same time changed/transformed through the method application.

Both CT and PT are relevant parameters that have to be considered in SME. They jointly constitute the so-called development situation. The development situation results from the combination of CT and PT. Both CT and PT are hierarchical constructs that can be refined/broken down into constituent CT factors and PT factors, respectively.

2.3 Method Fragments as Building Blocks in SME

The development situation – determined by CT and PT – influences the applicability of so-called method fragments.

Methods comprise specifications of both product and process aspects: A well-defined target/result is produced through specific activities and techniques (Avison and Fitzgerald 1988; Olle et al. 1988; Brinkkemper 1996; Harmsen 1997; Karlsson and Ågerfalk 2004; Karlsson and Wistrand 2006). In an analogous manner, we understand a method fragment as a combination of (one or multiple) design activities and (one or multiple) techniques that guide the creation of one particular design result (cf. Fig. 3). A method fragment therefore consists of a product description (i.e., the design result element) and a process description (i.e., the design activity and technique elements) (Cossentino et al. 2006; Agerfalk et al. 2007).

Fig. 3
figure 3

Elements of a method fragment. Adapted from Bucher (2008)

Full size image

Each method fragment can be identified unambiguously by its design result. As a consequence, the design result of a particular method fragment must be invariant. Viewed from the outside, i.e., to support the aggregation of multiple method fragments into a situational method, the design result is the only element of interest – irrespective of the way it is created. On the contrary, viewed from the inside, one or multiple design activities and one or multiple techniques guide the creation of the design result. Viewed from the outside, a method fragment is characterized by three attributes (Bucher 2008): (1) the design result that is created, (2) the pre-conditions that have to be met for a method fragment to be applicable (i.e., other design results that have to be created beforehand), and (3) the specification of (one or multiple) development situations in which the design result (and therefore the method fragment) generally matters.

By the use of well-defined adaptation mechanisms, method fragments can be adapted and combined into a situational method (Becker et al. 2007a, b; Bucher et al. 2007). The application of a situational method is effected by the selection and aggregation of method fragments based on the development situation at hand as well as on the preconditions specified for each fragment.

The following section reports on empirical results that form the basis for the engineering of situational methods to support BPM. On the basis of these empirical insights, an exemplary adaptation of a well-known BPM method is then sketched. This adaptation builds upon the theoretical arguments about situational method engineering made in the previous section.

3 Empirical Study on Business Process Management Approaches

The section at hand presents results and implications of an empirical study on BPM approaches. First, the data set is characterized and the course of analysis is described. In the two subsections that follow, the results of the exploratory analysis are presented. We distinguish four BPM realization approaches, allowing for the differentiation of five PTs that characterize BPM development situations. In the remainder of this chapter, we focus explicitly on the identification and discussion of PTs while abstaining from contemplating CTs. This restriction is due to the nature of the underlying data set. In order to complete the proposed taxonomy of BPM approaches, complementary CTs need to be specified, too. However, this will be subject to further research.

3.1 Data Set and Course of Analysis

Data for the exploratory analysis were collected by means of a written questionnaire distributed at two BPM forums held in Germany and Switzerland in 2005. The forum participants were specialists and executive staff, primarily working in IT or operating departments concerned with organizational issues and process management.

The questionnaire was designed to assess both the current and the target state of BPM within the interviewed organizations. For this purpose, appropriate statements were formulated, and the respondents were asked to indicate both the current realization degree (“as-is value”) as well as target values (“to-be values”) of each variable in their organization on a five-tiered Likert scale. Before being used at the forum, experts revised the questionnaire in reference to its comprehensibility.

A total of 47 questionnaires were returned. After the elimination of questionnaires with missing values or other quality problems, 38 observations remained and were included in the analysis. Although the sample size is rather small, the data set is considered to constitute an adequate basis for an exploratory analysis.

The interviewed organizations are primarily large and medium-sized companies (71% have more than 1,000 employees, and another 20% have more than 200 employees) from the German-speaking countries. The sectors mainly represented were banking, finance, and insurance (32%); manufacturing and consumer goods (15%); public administration and healthcare (11%); information technology (9%); and utilities (9% as well).

In addition to demographic characteristics and information on the stage of maturity of BPM, the data set comprises 31 variables describing the design of BPM. These variables can be grouped into the five categories: (1) communication of process management, (2) role of process managers, (3) process design, (4) process performance measurement, and (5) other initiatives pertaining to BPM. The variables summarized in these categories allow for a detailed characterization of actual BPM realization approaches and, consequently, for a well-founded derivation of BPM PTs (Bucher and Winter 2006, 2008). The accurate communication of the BPM initiative itself, the design and the documentation of processes, and of underlying process activities are equally important as the implementation of adequate organizational structures to foster and support BPM as a whole. Furthermore, process monitoring and control as well as quality management are critical to the success of any BPM initiative.

Data analysis was conducted as follows:

  • Factor analysis: To develop a deeper understanding of the current design factors of BPM, principal component analysis was conducted on the basis of the as-is values. Factor analysis can be applied to identify a small number of important and mutually independent factors from a multiplicity of contingent variables. As a result, four design factors of BPM were identified. BPM design factors summarize multiple variables (that have been included in the survey instrument) and can be used to characterize BPM realization approaches regarding specific thematic aspects of BPM.

  • Cluster analysis: Consecutively, the 38 observations (each one representing a different organization) were clustered on the basis of as-is factor values calculated in the first step. The hierarchical Ward algorithm and the squared Euclidean distance were used as fusion algorithm and distance measure, respectively. As a result, four generic BPM realization approaches can be distinguished.

  • Regression analysis: Finally, regression analysis was applied to calculate to-be factor values for each observation and each factor. On the basis of this information, target realization approaches could be determined for each organization surveyed. The comparison of the as-is and the to-be realization approaches yields five BPM PTs. Each PT represents a particular transformation path between two generic BPM approaches: one of the two BPM realization approaches that characterize a BPM PT serves as starting point, whereas the other realization approach represents the desired target state.

Comprehensive information and details of the statistical analysis can be found in our previous work (Bucher and Winter 2006, 2008).

3.2 BPM Design Factors

The factor analysis was conducted to gain insight into the dominant design factors of BPM. Principal component analysis (PCA) was chosen as extraction method. PCA is a technique for extracting a small number of mutually independent factors from a multiplicity of variables. It is aimed at answering the question of how to summarize the variables that load on a particular factor by the use of a collective term (Härdle and Simar 2003).

According to Dziuban and Shirkey (1974), a data set is appropriate for PCA if and only if the variables’ anti-image covariance, that is the share of a variable’s variance that is independent of the other variables, turns out as small as possible. Consequently, a set of variables qualifies for PCA if the proportion of nondiagonal elements in the anti-image covariance matrix that are different from zero accounts for 25% at the most. In the case at hand, this parameter value is about 17.6%. The measure of sampling adequacy (MSA, “Kaiser–Meyer–Olkin criterion”) is about 0.753. The MSA indicates whether or not a factor analysis can reasonably be performed on a given data set. Kaiser and Rice (1974) appraise a value of 0.7 and more as “middling.” Therefore, the data set is considered to be appropriate for applying PCA.

Four factors that jointly explain about 69.1% of the total variance were extracted by means of PCA (Eigenvalue >1.0; the scree plot heuristic points to this four factor solution as well). The component matrix was rotated using the Varimax method with Kaiser normalization to improve the interpretability of the variables’ assignment to factors.

According to our analysis, there are four design factors of BPM.Footnote 2 These can be interpreted as follows:

  • Design factor 1: Degree of performance measurement. A total of six variables were found to have a significant impact on the first factor. Our analysis results indicate that a high degree of performance measurement is characterized by (1.1) the usage of simulations for process design [e.g., van der Aalst et al. (2010)]; (1.2) the usage of surveys to assess the process customers’ satisfaction with the processes [e.g., see the “integrated customer opinion service” presented in vom Brocke et al. (2010)]; (1.3) the measurement of process cycle times [e.g., zur Mühlen and Shapiro (2010)]; (1.4) the measurement of process outputs and performances; (1.5) the fact that performance measures are available without undesirable time lags; and (1.6) the fact that performance measurement is supported by a workflow management system.

  • Design factor 2: Professionalism of process management. Four variables exhibit high loadings on the second factor. According to our analysis results, professional BPM is characterized by (2.1) the fact that the documentation of process performances and goals is common knowledge; (2.2) the fact that the documentation of non-financial measures is available to all employees without any restrictions [e.g., Hilti case in vom Brocke et al. (2010)]; (2.3) the existence of an organizational unit for strategic process management [e.g., Jesus et al. (2010)]; and (2.4) the existence of a dedicated education for process managers.

  • Design factor 3: Impact of process managers. Likewise, four variables were found to have significant impact on the third factor. Our analysis results show that the impact of process managers is positively influenced by (3.1) the fact that process management is located at a sufficiently high level in organizational hierarchy [e.g., Hilti case in vom Brocke et al. (2010)]; (3.2) the fact that process managers enjoy high prestige in the organization; (3.3) the fact that process managers have sufficient decision-making power in order to influence process design and execution; and (3.4) the fact that process managers are actively engaged in change projects.

  • Design factor 4: Usage of methodology and standards. Finally, the fourth factor is made up of four variables as well. Corresponding to our analysis results, usage of methodology and standards is characterized by (4.1) the usage of procedure models for the design of performance management systems, (4.2) the usage of reference process models for process analysis and design [e.g., Burlton (2010) and Aitken et al. (2010)], (4.3) the fact that the organization is ISO-certified, and (4.4) the fact that the organization uses the European Foundation for Quality Management (EFQM) approach to quality management.

Comprehensive information and details of the statistical analysis can be found in our previous work (Bucher and Winter 2006, 2008).

3.3 BPM Realization Approaches

On the basis of these design factors, four clusters can be distinguished that represent four distinct realization approaches of BPM. Fig. 4 exhibits the standardized arithmetic means of each of the 18 variables’ as-is values for each of the four clusters, grouped according to the four design factors.

Fig. 4
figure 4

Profile lines of the four current realization approaches of Business Process Management. Bucher and Winter (2006)

Full size image

These profile lines illustrate an obvious partitioning between two BPM approaches on the one hand, in the following referred to as “BPM freshman” (11 observations, i.e., 11 organizations) and “BPM intermediate” (seven observations), and the remaining two clusters on the other hand, subsequently labeled as “BPM collectivist” (nine observations) and “BPM individualist” (11 observations).

The first group (BPM freshman and BPM intermediate) is characterized by rather low realization degrees with respect to performance measurement, arrangements supporting the work of process managers, and usage of methodology and standards (design factors 1, 3, and 4). Organizations clustered into the second group (BPM collectivist and BPM individualist), however, show significantly higher implementation degrees in terms of these factors. Thus, both the BPM collectivist and the BPM individualist approach can be characterized as mature approaches to process management. Accordingly, our findings suggest that the maturity level of BPM is determined by the variables summarized in design factors 1, 3, and 4.

The BPM freshman approach is branded by exceptionally low professionalism of process management (design factor 2). For that reason, the BPM freshman approach contrasts with the BPM intermediate stage. Although rather immature as well, organizations in the BPM intermediate stage have at least started to pay a certain amount of attention to the implementation of BPM, for example, by establishing an organizational unit for strategic process management and a dedicated education for process managers.

In contrast to this classification which relies on the degree of attention paid toward process management, the differentiation between the BPM collectivist and the BPM individualist approach is residing at the design level (cf. Fig. 5). The former approach is characterized by reliance on established standards as well as on procedure and reference models whereas organizations having adopted the last-mentioned approach to process management strive to implement a more tailor-made type of BPM. Thus, the main differences between these two highly mature realization approaches of BPM do exist with respect to the professionalism of process management and the usage of methodology and standards (design factors 2 and 4).

Fig. 5
figure 5

BPM typology matrix with project types. Adapted from Bucher and Winter (2006, 2008)

Full size image

3.4 BPM Project Types

On the basis of the results of the regression analysis and a comparison of as-is and the to-be realization approaches, a total of five PTs for the engineering of situation-specific methods to support BPM can be identified. These PTs can be further subdivided into three of major importance (PTs 1–3, numerous cases in the data set) and two of minor importance (PTs 4 and 5, some isolated appearances):

  • Project type 1: BPM collectivist turning into BPM individualist. Seven organizations that have currently adopted the BPM collectivist approach were found to pursue the BPM individualist approach. Both approaches are characterized by high maturity but differ with respect to the design type of process management.

  • Project type 2: BPM freshman turning into BPM individualist. A total of ten organizations that have not yet begun or are at most about to deal with BPM were found to pursue the BPM individualist approach in the long run. This implies that those organizations need to improve the maturity of their BPM approach significantly and develop individual practices.

  • Project type 3: BPM intermediate turning into BPM individualist. Five organizations that currently reside on the BPM intermediate stage, that is, that have started to pay a certain amount of attention to the implementation of BPM, were found to pursue the BPM individualist approach. Similar to PT 2, these organizations need to both improve the maturity of their BPM approach and develop independent procedures for BPM at the same time.

  • Project type 4: BPM freshman turning into BPM collectivist. Just one organization that is branded with exceptionally poor professionalism of BPM was found to pursue the BPM collectivist approach in the long run. Because of the marginal number of relevant observations, this PT is considered to be of minor importance. We therefore refrain from discussing this PT in the remainder of this chapter.

  • Project type 5: BPM intermediate turning into BPM collectivist. Similarly, a mere two organizations that have currently adopted the BPM intermediate approach were found to purse the BPM collectivist approach. For the same reason as with PT 4, we refrain from discussing PT 5 in the following.

The four BPM realization approaches can be arranged in matrix format. This so-called BPM typology matrix is depicted in Fig. 5. We have added three arrows in light gray color, representing the three major PTs of BPM, and two arrows in dark gray color, in place of the two minor BPM PTs. The matrix illustrates a classification according to three dimensions:

  • Maturity level of process management: The classification of the four approaches depends on the BPM maturity level within the organization. This differentiation is in accordance with the obvious partitioning between the two bottom clusters (BPM freshman and BPM intermediate) on the one hand and the two top clusters (BPM collectivist and BPM individualist) on the other hand.

  • Attention paid toward process management: If the maturity level is rather low, it is assumed that BPM has not played any significant role within the organization in the past. However, the BPM freshman and the BPM intermediate approach can be differentiated with respect to the amount of attention that is currently paid toward process management.

  • Process management design type: On the contrary, if the maturity level of BPM is rather high (i.e., if the organization has dealt with the BPM concept for quite a long time), one can distinguish between two design types of process management. The BPM collectivist relies on established standards as well as on procedure models and reference models whereas the BPM individualist focuses on the adoption of a more tailor-made approach to BPM. For this purpose, the BPM individualist provides process managers with excellent education and far-reaching authority for decision-making with respect to process design and execution.

In our early work, we have argued that the BPM intermediate approach might be characterized as a transitional stage in an organization’s shift toward process-oriented thinking (Bucher and Winter 2006). According to the results of subsequent research, this assumption does not hold completely true (Bucher and Winter 2008): PT 2 is made up of ten observations that develop directly from the BPM freshman approach to the BPM individualist approach.

The common ground of the three major PTs of BPM is that the target state in all cases is the BPM individualist approach. When compared to the other realization approaches, this particular approach is characterized by the highest implementation level with respect to 10 out of 18 variables that have been sampled and included into the analysis (cf. Fig. 4). This fact indicates areas that need to be explicitly addressed in BPM transformation projects. The assessment of relative distances of the BPM collectivist, BPM freshman, and BPM intermediate implementation levels from the BPM individualist implementation level with respect to the 18 variables covered in our analysis points toward the topics that are of particular importance in each one of the three PTs, for example, the collection of process customers’ input regarding process design or the documentation of process performances and goals.

The section to follow will illustrate the exemplary adaptation of a well-known BPM method to account for the characteristics of the three major BPM project types that have been identified and discussed in the previous section.

4 Exemplary Adaptation of the “Process Innovation” Method

The following section demonstrates the applicability of the empirical results. We report on the exemplary adaptation of Davenport’s “process innovation” method (Davenport 1993). After giving a brief overview of the (generic) method for process redesign, we will sketch situation-specific embodiments of the method that are based on the PTs identified in the previous section.

4.1 Overview of the Method

In the early 1990s, during the pioneer era of business process reengineering (BPR), many authors have proposed concepts and methods for process innovation and redesign. Recommendations were made by both academia (e.g., Davenport and Short 1990; Hammer 1990; Harrington 1991, 1995; Davenport 1993; Hammer and Champy 1993) and practitioners. For a compilation and comparison of different approaches, see Hess and Brecht (1996).

The “process innovation” method proposed by Davenport (1993) is a well-known example of such an early BPR method. It aims at the fundamental and radical examination, analysis, and redesign of existing business processes with the objective of improving performance with respect to quality, flexibility, time, and money.

Figure 6 depicts the method’s procedure model as outlined by Davenport (1993). This method description is rather generic, that is, it is intended to be applicable to a variety of development situations. The procedure model of the generic method features 25 design activities grouped into five phases. To simplify matters, we will assume that one or multiple design activities described by Davenport (1993) yield one particular, common design result. We will furthermore abstain from discussing both roles and techniques in support of the design results’ creation.

Fig. 6
figure 6

Procedure model of the “process innovation” method (on the basis of Davenport, 1993)

Full size image

Figure 7 depicts the documentation model that has been deduced from the description of the “process innovation” method. The documentation model shows all design results that arise from the method’s application as well as their mutual dependencies. In accordance with the terminology established in this chapter (cf. section “situational method engineering”), we refer to the combination of design activities and associated design results as method fragments. Each method fragment is characterized by (1) the design result that is created and (2) the preconditions that have to be met for the fragment to be applicable. The third attribute necessary for the complete description of a method fragment – the specification of development situations in which the design result matters – will be introduced in the subsequent section.

Fig. 7
figure 7

Documentation model and method fragments deduced from the description of the “process innovation” method

Full size image

4.2 Situation-Specific Embodiments of the Method

For the engineering of situation-specific embodiments of Davenport’s BPR method, we focus on the major PTs 1–3, that is, BPM collectivist, BPM freshman, and BPM intermediate turning into BPM individualist. Moreover, we concentrate on selected variables of the empirical analysis: variable 1.2 (“surveys are used to assess the process customers’ satisfaction with the processes”), variable 1.4 (“process outputs and performances are measured”), variable 2.1 (“the documentation of process performances and goals is available without restriction to all employees”), variable 3.4 (“process managers are actively engaged in change projects”), variable 4.1 (“procedure models are used for the design of performance management systems”), variable 4.2 (“processes of competitors and/or reference processes are used for process analysis and design”), and variable 4.4 (“the organization uses the EFQM approach to quality management”).

From the information depicted in the profile lines of the current BPM realization approaches (cf. Fig. 4), we can observe the following differences between these approaches (and consequently between the PTs):

  • As for variable 1.2, the BPM individualist approach exhibits an implementation level slightly below the BPM collectivist approach. However, BPM freshman and BPM intermediate fall considerably short of this standard. The same holds true for variable 3.4. Variables 1.2 and 3.4 are particularly dealt with in conjunction with method fragment 6.

  • As for variables 1.4, 4.1, and 4.2, the BPM individualist and the BPM collectivist approach exhibit implementation levels that are approximately equal to each other (with the BPM individualist approach scoring slightly higher). By contrast, the respective implementation levels of the BPM freshman and the BPM intermediate approach are significantly lower. Variable 1.4 is addressed by method fragment 10. Variables 4.1 and 4.2 relate to method fragment 07.

  • As for variable 2.1, the BPM intermediate approach exhibits an implementation level that is approximately equal to the BPM individualist approach. The respective implementation levels of the BPM collectivist and the BPM freshman approach are considerably below this level. Variable 2.1 is not addressed by any of the fragments proposed by Davenport (1993). A new fragment therefore needs to be introduced to deal with this variable.

  • As for variable 4.4, the BPM intermediate and the BPM individualist approach exhibit similar implementation levels that are significantly lower when compared to the BPM collectivist approach. When compared to the other three approaches, the BPM freshman approach scores lowest. The “process innovation” method does not explicitly address this variable. However, fragments 04 and 05 may be supported through the adoption of the EFQM approach.

Consequently, PT 1 (BPM collectivist turning into BPM individualist) needs to focus on the improvement of the implementation level with respect to variable 2.1 and might, at the same time, reduce the respective level of variable 4.4. PT 2 (BPM freshman turning into BPM individualist) needs to account for all of the aforementioned variables. PT 3 (BPM intermediate turning into BPM individualist) must focus on the improvement of variables 1.2, 1.4, 3.4, 4.1, and 4.2. From the fragment perspective, the new fragment introduced to deal with variable 2.1 (fragment 18; “documentation of process performances and goals”) is of particular importance for PTs 1 and 2 but might be neglected in conjunction with PT 3. PT 1, by contrast, does not have to deal too much with fragments 6, 7, and 10. Those fragments are especially important to PTs 2 and 3. PT 3 might skip fragments 4 and 5.

Both Figs. 8 and 9 summarize these thoughts and propose a set of situation-specific embodiments of the “process innovation” method. The fragment list (cf. Fig. 8) depicts the fragments of the situational method. Changes with respect to Fig. 7 are marked with a diagonal shade. The network diagram (cf. Fig. 9) shows the generic method in continuous bold lines. Particular variations of this standard procedure that are valid for individual PTs alone are displayed in dashed lines (see figure key). To engineer a situational method that might be applied in real-world organizations, the required method fragments need to be selected and aggregated subject to the PT at hand.

Fig. 8
figure 8

Situation-specific embodiments of the “process innovation” method (fragment list)

Full size image
Fig. 9
figure 9

Situation-specific embodiments of the “process innovation” method (network diagram)

Full size image

5 Conclusion and Outlook

Our work is motivated by the conviction that no artifact (e.g., reference model or method) fits all development/application situations. On the one hand, a large range of development/application situations may be covered by an extremely generic artifact – but its generality makes it hard to concretely solve a specific problem. On the other hand, concrete problem situations may be addressed by a very specific artifact – but then, reuse potentials are very limited, and artifact development is hard to justify. Situational methods try to combine the best of both worlds: although such methods are designed as generic as possible, they can be adapted to fit a certain range of specific problem situations.

In order to engineer the generic method and appropriate adaptation mechanisms, a deep understanding of problem situations is needed. As our goal is to develop a situational approach to BPM, we therefore conducted a survey which, in a first step, identified four distinct design factors of BPM: (1) the degree of process performance measurement, (2) the overall professionalism of process management, (3) the impact of process managers, and (4) the utilization of established methodology and standards. On the basis of these design factors, four generic approaches to BPM were differentiated in a second step which we designated as (1) “ BPM freshman,” (2) “BPM intermediate,” (3) “BPM collectivist,” and (4) “BPM individualist.” When interpolating the actual BPM approach with BPM plans in the near future, five BPM project types were differentiated in a third step: (1) BPM collectivist turning into BPM individualist, (2) BPM freshman turning into BPM individualist, (3) BPM intermediate turning into BPM individualist, (4) BPM freshmen turning into BPM collectivist (rare), and (5) BPM intermediate turning into BPM collectivist (rare). All surveyed organizations strive to achieve high BPM maturity. There are, however, significant differences with respect to the particular design of the aspired approaches to mature BPM.

The presented knowledge about design factors, generic approaches, and in particular PTs allows for developing a “customized” BPM method: The analysis of the relation of method fragments and fragment dependencies to PTs leads to a “core method,” which can be systematically adapted by additional fragments and/or alternative fragment dependencies in order to fit certain PTs. The applicability of this approach to real-world BPM methods has been shown by using Davenport’s “process innovation” method as a test case.

Future research is needed to further validate the empirical findings regarding BPM design factors, generic approaches to BPM, and BPM project types. On the basis of a growing common understanding of BPM situations, more case studies have to justify the usefulness of the proposed situational method engineering approach.