Business & Information Systems Engineering

, Volume 59, Issue 4, pp 251–275 | Cite as

Meta Modeling for Business Process Improvement

Research Paper


Conducting business process improvement (BPI) initiatives is a topic of high priority for today’s companies. However, performing BPI projects has become challenging. This is due to rapidly changing customer requirements and an increase of inter-organizational business processes, which need to be considered from an end-to-end perspective. In addition, traditional BPI approaches are more and more perceived as overly complex and too resource-consuming in practice. Against this background, the paper proposes a BPI roadmap, which is an approach for systematically performing BPI projects and serves practitioners’ needs for manageable BPI methods. Based on this BPI roadmap, a domain-specific conceptual modeling method (DSMM) has been developed. The DSMM supports the efficient documentation and communication of the results that emerge during the application of the roadmap. Thus, conceptual modeling acts as a means for purposefully codifying the outcomes of a BPI project. Furthermore, a corresponding software prototype has been implemented using a meta modeling platform to assess the technical feasibility of the approach. Finally, the usability of the prototype has been empirically evaluated.


Business process improvement Meta modeling Roadmap 

1 Introduction and Motivation

Improving the quality of products and services ranks among the top priorities of a company’s C-level executive these days (Davis 2013; McDonald and Aron 2011; Harmon 2016). Thus, business process improvement (BPI) is a major success factor for organizations in their effort to provide high service and product quality in order to attain customer loyalty and establish long-term customer relationships (Becker and Kahn 2012; Klefsjö et al. 2008; Low et al. 2015; Turkyilmaz et al. 2013; vom Brocke et al. 2014; Zu 2009). The ability to satisfy customer requirements decisively influences a company’s market success (Shamma and Hassan 2013; Rigby and Bilodeau 2015) and is a prerequisite for achieving the strategic objectives (Davis 2013).

At the same time, highly competitive markets force companies to increase the efficiency of their business routines and to reduce costs (Davis 2013; Heckl et al. 2010; Sarkar and Moon 2014; Rigby and Bilodeau 2015). This balancing act between fulfilling customer requirements and reducing process execution costs is often perceived as challenging (Persson 2013).

For that reason, methods to optimize business and process performance, such as Six Sigma (Snee and Hoerl 2003), Theory of Constraints or Lean Management (Womack et al. 2007), have gained considerable attention in practice in the last couple of years (Davis 2013; Psomas et al. 2011; Harmon 2016). These approaches build on procedure models, e.g., the Define-Measure-Analyze-Improve-Control (DMAIC) cycle (Snee and Hoerl 2003), and provide techniques for generating results, e.g., the value-stream-map (Womack and Jones 1996), thus supporting employees in conducting BPI projects. Besides, academia has made beneficial contributions to the systematic optimization of process and business performance. These contributions come in various forms such as modeling methods, e.g., the Horus modeling method (Schönthaler et al. 2012), conceptual methods structuring BPI initiatives, e.g., the SUPER method (Lee and Chuah 2001), or automatic approaches for analyzing business processes regarding weaknesses (Höhenberger and Delfmann 2015).

However, conducting BPI projects has become challenging for modern enterprises, and many initiatives fall short of their initial aim (Breyfogle 2010). A major reason is that customer requirements are rapidly changing due to high market transparency and quickly evolving technologies (e.g., “social media” or “internet of things”) (Bruhn 2013; Greenberg 2010; Lewis 2007; Turber et al. 2014; Weber and Weber 2010), which makes it hard to keep pace with shifting consumer needs. Moreover, successful BPI projects require the participation of employees engaged in the daily business routines of a company who have to be motivated to take part in the corresponding improvement efforts (Seethamraju and Marjanovic 2009). Generally, a huge amount of knowledge (e.g., on process weaknesses) is externalized in BPI projects, which needs to be adequately documented, communicated within the workforce, and processed for purposefully deriving suggestions for improvement.

In order to deal with this complexity of performing BPI projects and the involved massive amount of information generated, we will first focus on enterprise modeling to address these issues (Wand and Weber 2002; Mylopoulos 1992). Enterprise modeling has traditionally been used in business and information systems engineering for describing an application domain, for gathering and analyzing requirements of information systems (IS) by representing their static and dynamic phenomena, and for the description of existing or future system solutions (Thalheim 2010; Wand and Weber 2002). However, the use of enterprise models in today’s companies extends far beyond the traditional IS field as these models have established as efficient means to structure manifold problem domains (e.g., strategic planning, IT architectures), to effectively support the codification of knowledge and its transformation into information to be further processed (Anaby-Tavor et al. 2010; Hall 2006). In this way, enterprise models also facilitate the organization’s sharing and use of knowledge emerging in BPI initiatives (Dalkir 2005; Le Dinh et al. 2014). Second, we will draw upon the idea of “roadmaps”, which are a commonly used technique for capturing tacit knowledge of individuals and groups alike (Dalkir 2005; Erdani et al. 2004). In the context of BPI, a roadmap (Dalkir 2005) can be understood as a logical arrangement of a limited number of BPI techniques (e.g., Bamford and Greatbanks 2005), with each technique producing a particular result (e.g., key performance indicators to measure process performance) in the course of a BPI project (Gutzwiller 1994). The BPI techniques assigned to the roadmap cover all the mandatory phases (Povey 1998) which structure a BPI project (e.g., the phases of the DMAIC cycle) and, hence, the roadmap suggests certain techniques to be applied at a specific point during BPI project execution. The results produced when using the roadmap are documented in the form of diagrams, tables and sketches (Anaby-Tavor et al. 2010), and the roadmap itself can be specified via meta models (e.g., Kühne 2006) as shown later on.

Against this background, the contribution of our research is as follows: first, we introduce a roadmap which supports the goal-oriented execution of BPI projects as well as the systematic development of suggestions to overcome process weaknesses. The roadmap, called “BPI roadmap” hereafter, is designed as a logically arranged procedure building on BPI techniques, perceived as easy-to-use by practitioners, eliciting the project participants’ process knowledge to derive proposals for process improvement. Thus, a means for purposefully steering BPI projects is created while at the same time the challenge of selecting appropriate BPI methods and techniques (Hagemeyer et al. 2006) is mitigated. Further, practitioners’ current needs are served through receiving a practicable approach for BPI that may substitute traditional as well as overly complex BPI methods and is also perceived as easy-to-use from a practitioner’s perspective (Davis 2013). In literature, a BPI technique or a BPI approach, respectively, are attested to be “easy-to-use” if their functioning is highly understandable for users, their application quickly learnable, and their handling in the course of a project flexible (Dale and McQuater 1998; McQuater 1995; Thia et al. 2005). A flexible handling is characterized by the option to adapt the functionality of a BPI technique or a BPI approach to better match the encountered project situation (Thia et al. 2005). For instance, the user of the Ishikawa Diagram (Ishikawa 1980) may classify potential problem causes according to standardized problem categories (e.g., the “M-categories” – machine, material, measurement, etc.) or categories that were individually defined for a particular project (Meran et al. 2013).

As a second contribution, a domain-specific modeling method (DSMM) (Frank et al. 2008; Frank 2010; Gray et al. 2007) is developed based on the BPI roadmap. The model types offered by the DSMM help to efficiently communicate and share the knowledge emerging in BPI projects among project members and within a company alike. Further, reports to purposefully analyze the knowledge captured in the model types are introduced, which facilitates decision-making in BPI projects accordingly.

The third contribution is the implementation of the DSMM as a prototypical modeling tool that supports the application of the BPI roadmap, processes the knowledge codified in the form of conceptual models, and automatically generates reports from the results created. The DSMM is evaluated by using its realization as a tool, with the evaluation being a crucial step in the design of modeling methods (Siau and Rossi 2011). The DSMM is thus closely related to the underlying technical platform, which suggests the evaluation of the DSMM on the base of its prototypical implementation (Fill and Karagiannis 2013).

Our paper has the following structure: in the subsequent Sect. 2, we will provide in brief foundations for our approach from the areas of BPI and modeling methods. In Sect. 3, the development procedure for designing the DSMM and its technical implementation, using a meta modeling platform, are described. The DSMM and the resulting prototype are then evaluated to assess their suitability regarding an application in practice, which is shown in Sect. 4. Afterwards, the benefits for research and practice are discussed (Sect. 5). The paper concludes with a summary, limitations, and an outlook on further research (Sect. 6).

2 Foundations

This section provides the reader with current challenges of conducting BPI projects, deals with the selection of BPI techniques, and presents foundations of modeling methods.

2.1 Challenges in Conducting BPI Projects

According to literature, a considerable proportion of BPI efforts in service as well as production enterprises fail and do not lead to sustainable developments (Breyfogle 2010; Chakravorty 2010).

In that context, three major challenges are encountered in practice: first, as mentioned above, today’s enterprises need to be aware of rapidly changing customer requirements (Greenberg 2010; Lewis 2007; Mukerjee 2013). New technologies provide customers with instant information on products and services, enabling them to compare prices and share their experience with other net users (Kaplan and Haenlein 2010; Lymperopoulos et al. 2013). Consequently, customers have become less loyal and more price-sensitive, which hampers long-term customer relationships (Mukerjee 2013; Rigby and Bilodeau 2015; Lovelock and Wirtz 2011; Shamma and Hassan 2013). In consequence, an enterprise has to continuously analyze the frequently changing customer requirements and to optimize its services and products accordingly (Mukerjee 2013).

Second, in times of globalization, companies are increasingly engaged in networks of firms that conjointly create “value” (Womack et al. 2007) in inter-organizational business processes (Mellat-Parast 2013; Feller et al. 2013; Telang and Singh 2012). In such settings, successful BPI projects require all cooperating partners to participate in the initiative, with an end-to-end perspective on the business processes across enterprises being needed (Breyfogle 2010; Mellat-Parast 2013). Thus, the results and emerging knowledge of BPI projects need to be properly codified and communicated to avoid rework and undoing benefits once achieved (e.g., Samson and Challis 2002). However, the question of how to efficiently and descriptively document project results remains unanswered by the majority of BPI approaches as introduced in literature (Adesola and Baines 2005; Coskun et al. 2008; Harrington 1991; Povey 1998).

Third, many well-established methods used for process improvement (e.g., TQM and Six Sigma) are increasingly perceived as overly complicated and over-dimensioned by firms (Davis 2013; Balestracci 2009). In that context, not only the high amount of human resources required for applying the BPI approaches is seen as challenging but also employees’ defensive attitude towards familiarizing themselves with these methods (Davis 2013; Gijo et al. 2005). This is problematic since the success of BPI projects largely depends on the participation of employees who explicate their knowledge on potential problems, which then is transformed into solutions (Seethamraju and Marjanovic 2009). Consequently, recent studies indicate that companies prefer to use few selected and easy-to-use BPI techniques instead of applying holistic methods in BPI projects (e.g., Six Sigma) (Davis 2013).

A BPI technique is a mandatory element of a BPI method (e.g., de Mast 2004), which produces a particular result in the course of a project (Gutzwiller 1994). For instance, the Measurement Matrix provides key performance indicators (KPIs) as output, which are used to measure the current process performance (Meran et al. 2013; George et al. 2005). In contrast, a BPI method is a superior construct, which further subsumes a procedure model (e.g., the DMAIC cycle) and roles, e.g., “Black Belt”, in addition (Pande et al. 2000; Gutzwiller 1994; Snee and Hoerl 2003). In that context, the application of certain BPI techniques in the course of a project is determined by the procedure model of the BPI method (Johannsen 2011).

However, even the application of a limited set of BPI techniques for deriving improvement potentials needs to be properly coordinated. Often, the interdependencies that exist between BPI techniques are not fully understood or ignored (Bruhn 2013). These interdependencies may be of a functional (e.g., the output of a technique serves as input to another technique) or goal-related nature (e.g., cost-oriented vs. customer-oriented techniques) for example (Bruhn 2013). The successful execution of BPI projects in an enterprise requires a manageable set of BPI techniques that are compatible with one another and universally applicable for projects of varying goals. Nevertheless, generally valid suggestions as to which BPI techniques are to be used for certain project constellations do not yet exist.

Additionally, also the existence of regulatory standards (e.g., Sarbanes–Oxley, Basel III) as well as employees’ resistance to change come up as topics to be dealt with in BPI projects (Rafferty et al. 2013; Hanif et al. 2014), which are, however, not explicitly addressed in the further course of this research. This is because regulatory standards affect the design of a proposed should-be process in the corresponding phase of a BPI project, e.g., improvement phase (Pande et al. 2000), and do not immediately influence the structured execution and organization of an initiative per se. Further, ensuring employees’ commitment is usually a matter of change management (Todnem By 2005) in the follow-up of BPI projects and thus is out of the scope of our solution supporting the development of suggestions to overcome process weaknesses.

2.2 Techniques in BPI

Over the decades, BPI has introduced a multitude of BPI techniques (Meran et al. 2013; George et al. 2005; Kettinger et al. 1997). In preparation of a BPI project, especially the selection of those techniques to be used in the project and the question of how to document the results of the initiative need to be considered. In that context, the following facts should be acknowledged.

First, to support the selection of suitable BPI techniques, several authors have undertaken efforts to classify them according to their functionality. For example, Okes (2002) differentiates between the “seven management tools (7M)”, “seven basic tools (7Q)”, “creativity tools”, “statistical tools”, “design tools” and “measurement tools”. The categories “7Q” and “7M” tools, as initially introduced by Ishikawa (1980) resp. Nayatani (1986), are taken up by Dale and McQuater (1998) as well. Further, the “7 × 7 Toolbox” is presented in the context of the Six Sigma approach, which is a collection of 49 techniques suggested to be used in Six Sigma projects (Magnusson et al. 2004). However, as Meran et al. (2013) show, also the stages of BPI projects (e.g., the DMAIC cycle) can be used to structure and classify the large amount of existing BPI techniques. Therefore, these structuring propositions help to understand at what stage of a project (e.g., analysis of process weaknesses) a technique may be applied.

Second, to further judge the appropriateness of techniques to be applied in a particular project, more sophisticated selection approaches have been developed recently (Hagemeyer et al. 2006; Johannsen et al. 2015), which build on criteria to evaluate the applicability of BPI techniques in a certain project environment. Manifold criteria are found in literature in that context. For example, Thia et al. (2005) introduce 13 criteria to specify techniques supporting product development. McQuater et al. (1995) introduce the criteria “tangibility”, “importance for staff”, “relevance” as well as “frequency of use” to rate BPI techniques. Griesberger et al. (2011) evaluate 36 BPI techniques in terms of their impact on business process elements (e.g., activity) as well as process success dimensions such as quality, cost or time.

Third, literature mentions the proper documentation of the results achieved by applying the BPI techniques as an important aspect in practice to enable the coordination of project teams and BPI efforts run in parallel (e.g., Breyfogle 2010). In that context, the BPI discipline offers a variety of diagram types such as the SIPOC Diagram or the Ishikawa Diagram that codify results of a project in the form of conceptual models allowing their easy documentation and communication equally (Ishikawa 1980; Meran et al. 2013). However, corresponding presentation mechanisms are not proposed for all BPI techniques introduced in literature alike, e.g., “process simplification” (Harrington and Lomax 2000) or “redundancy elimination” (Andersen 1999). As a consequence, manifold forms of codifying results are reverted to in practice such as tables, lists or sketches (Anaby-Tavor et al. 2010), which may be created by using software (e.g., MS Office packages, drawing tools) or flipcharts amongst others. This diversity of documenting results using different forms of representation and storage media often hampers the efficient exchange of results.

Summarizing, what practitioners miss so far, is a manageable set of easy-to-learn and established BPI techniques that can be used for conducting improvement projects of different scopes in service as well as in production industries. While the aforementioned approaches may support an enterprise in selecting BPI techniques, they still require profound knowledge of the BPI discipline for being able to perform the evaluation accordingly. However, enterprise employees usually do not have this knowledge (Gijo et al. 2005). Further, considering a potential set of easy-to-learn and proven techniques, a logical arrangement – in the form of a roadmap (Dalkir 2005) supporting all mandatory steps of a BPI project (e.g., Pande et al. 2000) – should be given, indicating which technique is to be used at a certain project stage (e.g., Ishikawa Diagram for structuring problem causes). Additionally, means to adequately capture the project outcomes, e.g., by conceptual model types (Anaby-Tavor et al. 2010), are required to enable their efficient communication. The research at hand addresses these particular needs by developing a BPI roadmap, a DSMM and an executable prototype (Sect. 1).

2.3 Modeling Methods and Meta Modeling

As mentioned, in addition to the design of the BPI roadmap and the corresponding tool support, we also strive for developing a domain-specific modeling method (DSMM) in this research to codify, document and share results of a BPI project. For the domain of BPI where the interaction of large numbers of users needs to be enabled who primarily possess little technical knowledge, we focused on semi-formal, visual modeling languages. In contrast to mere drawings as they are typically created during meetings using flipcharts, the semi-formal nature of the resulting models permits to apply IT-based processing functionalities such as the automated generation of reports, statistical processing, or interfacing IT systems (Bork and Fill 2014).

In order to process conceptual models by machines and to achieve an inter-subjective and mostly unambiguous understanding of the concepts used, the use of formal specifications is regarded as essential (Mylopoulos 1992). Besides various logic-based formalisms (e.g., Koubarakis and Plexousakis 1999; Studer et al. 1998) that have been used for this purpose, approaches based on formal and semi-formal languages have been found to be particularly appropriate (Strahringer 1996; Karagiannis et al. 2008). Whereas the syntax and semantics of formal modeling languages are specified using formal languages, semi-formal variants only provide formal definitions of the syntax with the semantics being informally expressed in natural language (Fraser et al. 1994; Harel and Rumpe 2000).

For example, many semi-formal modeling languages, e.g., Event-driven Process Chains (Scheer and Schneider 2006), have a formally defined syntax by reverting to meta models, but lack a formal description of the inherent semantics, i.e., the meaning of the resulting model elements (Bork and Fill 2014), which could generally be achieved with the help of ontologies for instance (Höfferer 2007; Fill 2016). Following this observation, a fully formal model representation is given in case the syntax, the structural and behavioral semantics as well as the static and dynamic notations are formally described, i.e., their specification is unambiguous and intersubjectively understandable (Bork and Fill 2014). Profound details about the formalization of current enterprise modeling methods can be found in Bork and Fill (2014).

The realization of the above mentioned processing functionalities together with guidelines on how they are used – based on the created models – leads to the conceptualization of modeling methods, an issue that we will denote as “meta modeling” in the following (Karagiannis und Kühn 2002; Siau and Rossi 2011).

In general, conceptual modeling methods are composed of a modeling language, mechanisms and algorithms, and a modeling procedure. The modeling procedure describes how to use the language and algorithms for creating results (Karagiannis and Kühn 2002). The modeling language itself can be decomposed into a syntax defining the grammar of the language, a notation visualizing the syntax and the semantics, which describes the meaning of the syntax (Fig. 1). Additionally, different forms of mechanisms and algorithms enable the processing of the model content by machines (Karagiannis and Kühn 2002).
Fig. 1

Components of modeling methods (Karagiannis and Kühn 2002)

In that context, the abstract and the concrete syntax have to be differentiated. The concrete syntax is used for describing the model instances with a specific notation, e.g., a visual or a textual notation. On the other hand, the abstract syntax specifies the elements of a modeling language and the rules how they may be combined to receive valid statements. The abstract syntax is also often referred to as the meta model (Harel and Rumpe 2004).

Thus, interdependencies between the modeling language, the modeling procedure and the corresponding mechanisms and algorithms need to be taken into account when designing modeling methods to ensure the efficient processing of information in terms of computation and storage (Fill and Karagiannis 2013).

A modeling language, as a component of a modeling method (Fig. 1), can be classified as a “general purpose modeling language (GPML)” that can be used for many application domains, e.g., the Unified Modeling Language (UML) (OMG 2015), or a “domain-specific modeling language (DSML)” developed for a particular field of application (Frank 2011a). Correspondingly, domain-specific modeling methods (DSMM) revert to DSMLs (domain-specific modeling languages) and introduce modeling procedures and associated mechanisms & algorithms in addition. Examples of DSMM comprise methods such as Horus for codifying knowledge about business processes focusing not only a strategic perspective but also the actual execution layer in terms of XML nets (Schönthaler et al. 2012) or the RiskM method (Strecker et al. 2011) for codifying knowledge about risks in business processes by help of the MEMO (Multi-Perspective Enterprise Modeling) approach (Frank 2011b). Further, the SeMFIS method for codifying and simulating risks in business processes reverting to semantic annotations can be mentioned as an example (Fill 2012).

3 Meta Modeling for BPI

In the previous Sect. 2.1, we highlighted several challenges of performing BPI projects. To provide a solution supporting the goal-oriented execution of BPI initiatives, we build on conceptual modeling and the concept of “roadmaps” (Dalkir 2005). However, for the purpose of properly codifying emerging results, a DSMM and tool support (e.g., Xu et al. 2011) are required in addition.

Considering this, with our solution – a roadmap supporting BPI projects, a corresponding DSMM and a software prototype –, we mitigate the problem of selecting adequate BPI techniques as these are predefined by the BPI roadmap. Further, the techniques are directly applicable by project participants. Via the DSMM and the software prototype, we offer means to communicate emerging results within the firm and across company boarders, thus supporting the execution of BPI projects in a collaborative setting. Emphasis is placed on the identification of customer requirements to arrive at solutions that meet consumers’ expectations.

3.1 Procedure of the Research

Our research follows the procedure as depicted in Fig. 2, which is similar to the Model-based and Incremental Knowledge Engineering (MIKE) development process as established in knowledge engineering (Angele et al. 1998) and also builds on the principles of Design Science (Gregor and Hevner 2013; Hevner et al. 2004; Lipton 2010). The procedure comprises steps addressing the development of a concept to purposefully conduct BPI projects (BPI roadmap), the design of a DSMM with the corresponding model types, its formalization, and the realization as a modeling tool. By this arrangement, smooth transitions can be achieved from semi-formal (e.g., meta models) over formal to implementation-oriented representations (Angele et al. 1998), which generally emerge when transferring conceptual solutions or knowledge representations to an executable software tool (Studer et al. 1998).
Fig. 2

Procedure of the research (extended from Johannsen and Fill 2015)

In a first step of our research (conceptual solution development), the creation of the “BPI roadmap” as a conceptual solution to systematically support the execution of BPI projects is performed. Afterwards (design), an integrated meta model of the BPI roadmap is designed, which describes the conceptual model types of our DSMM used for codifying emerging results of a BPI initiative. The meta model is represented by a UML class diagram, which has a semi-formal nature, i.e., it lacks formal specifications, e.g., for deriving the correct instantiation of models (Bork and Fill 2014). At this stage, it is thus not ensured that all details are contained in the meta model and all information is consistent, which is necessary for a subsequent technical implementation.

In a third step (formalization), the meta model is therefore formalized to prepare the ground for its implementation as a modeling tool and to assess its validity.

Then (development), implementation-oriented representations of the meta model are derived, which contain additional information required for the implementation, such as information on algorithms or the modeling procedure (Angele et al. 1998). In the deployment phase, the modeling tool is actually created by reverting to the formal specification and the implementation-oriented representations as established in prior steps. In so doing, the tool is transferred from the development environment to a stand-alone tool.

The modeling tool is subject to evaluation (activity “evaluation”) with valuable insights drawn regarding the results established throughout the development procedure. Additionally, the concept of the BPI roadmap is evaluated in several BPI projects in practice, while the formal specification of the meta model serves as a means to assess its consistency or syntactical correctness amongst others (Fraser et al. 1994).

In the following sections, each step of the development will be explained in more detail.

3.2 Conceptual Solution Development

The development of a roadmap for conducting BPI projects followed a five-step procedure based on the Design Science paradigm (Hevner et al. 2004; Lipton 2010). A more detailed description can also be found in Johannsen and Fill (2014a, 2016).

In a first step, requirements for the design of a generally valid roadmap for BPI projects across branches and companies of different sizes were derived from literature (e.g., Bruhn 2013; Bunney and Dale 1997; Dale and McQuater 1998; McQuater et al. 1995; Thia et al. 2005). In total, nine requirements were defined and categorized according to the “scope of the BPI roadmap”, “property of techniques”, and “interdependencies between techniques” (Table 1).
Table 1

Requirements on the roadmap (Johannsen and Fill 2014a)


Requirements (Rq)

Scope of the BPI roadmap

Rq1: Manageable set of techniques (10–15)

Rq2: Support of all stages of the DMAIC cycle

Property of techniques

Rq3: Consideration of team-oriented techniques

Rq4: High understandability and learnability

Rq5: Flexible handling

Rq6: Autonomy of techniques

Rq7: Operational character

Interdependencies between techniques

Rq8: Sequential ordering of techniques

Rq9: Complementary interdependencies

The category “scope of the BPI roadmap” comprised two requirements. First, only a manageable set of BPI techniques (10–15) was to be considered by the roadmap (Rq1). Second, techniques to support all mandatory stages of a BPI initiative were to be offered (Rq2). The “property of techniques” category referred to the inherent characteristics of the techniques, e.g., “high understandability” or “flexible handling” (Rq4 and Rq5). Additionally, each BPI technique was supposed to generate a particular result in a project on its own without a further technique having to be applied, a requirement denoted as the “autonomy of a technique” in the following (Rq6). For instance, the sole application of the SIPOC Diagram is appropriate for creating an abstract process visualization without further techniques, e.g., a map of the process landscape, being required (Meran et al. 2013). More, the techniques should be suitable for being used in teams (Rq3) and take an operational perspective on the process to be improved (Rq7) (e.g., the sequencing of certain process activities) instead of a strategic view (e.g., the impact of the business process on a company’s strategic goals).

The interrelations of the techniques were specified via the category “interdependencies between techniques”. Thus, a sequential arrangement of BPI techniques in the roadmap was strived for (Rq8). Additionally, results produced by one technique were meant to be taken up and further processed by a subsequent technique (Rq9).

In the following steps two and three, a set of 107 BPI techniques was derived from literature (George et al. 2005; Griesberger et al. 2011; Hagemeyer et al. 2006; Kettinger et al. 1997; Meran et al. 2013; Pande et al. 2000) and reflected against the criteria Rq1 to Rq7.

The purpose was to assess as to what degree the BPI techniques fulfilled the requirements to find potential techniques to become elements of the BPI roadmap. The corresponding evaluation of BPI techniques on the basis of the abovementioned criteria was performed in group discussions with six BPI experts of a German automotive bank (Johannsen and Fill 2014a).

Regarding the large number of techniques investigated, group discussions with selected experts were seen as an appropriate approach for coming to a roadmap supporting the execution of BPI projects (Johannsen and Fill 2014a). Following this procedure, 16 BPI techniques were selected and subsequently applied in various BPI projects at the automotive bank over a period of one year. In that context, the properties of the BPI techniques (Rq3 to Rq7 in Table 1) were to be evaluated once again, this time, however, during the application in the corresponding projects. For instance, it was to be investigated whether the project participants really perceived the techniques applied to be highly understandable (Rq4) or whether some techniques turned out to be more flexible to handle than others (Rq5).

Based on the feedback received by employees engaged in the projects, eleven techniques eventually turned out to be applicable candidates for the roadmap.

In a fourth step, the techniques were sequentially arranged to form a roadmap (Rq8), and the output of one technique was supposed to serve as the input of a subsequent technique at the same time (Rq9).

Finally (step five), the roadmap was evaluated in several BPI projects to gain insights into the suitability of the logical arrangement of the techniques. Figure 3 provides an overview of the BPI roadmap.
Fig. 3

Overview of the BPI roadmap (extended from Johannsen and Fill 2014a, b)

The BPI roadmap structures BPI projects according to the phases “Define”, “Measure”, “Analyze”, “Improve” and “Control” derived from the Six Sigma approach (Snee and Hoerl 2003).1

The BPI techniques are executed in a sequential order (Rq8 and Johannsen and Fill 2014b). By means of the “SIPOC Diagram” and the “CTQ/CTB Matrix”, the process to be improved is modeled on an abstract level and customer or employee requirements are transformed into “Critical-to-Quality (CTQ)” and “Critical-to-Business (CTB) factors”, respectively. These factors capture the key necessities of internal and external customers alike and specify the project goals (Pande et al. 2000). For measuring the goal realization level, key performance indicators (KPIs) are defined and prioritized (Measurement Matrix). After gathering process data – with the “Data Collection Plan” organizing the collection –, histograms and scatterplots are used to analyze the current process performance. Subsequently, causes of insufficient process performance are identified with the help of the “Ishikawa Diagram” and solutions are worked out (Affinity Diagram). Once the solutions have been realized, guidelines for avoiding process variances (Reaction Plan) are laid down and the effectivity of the solutions is judged (Control Charts) (Johannsen and Fill 2014a, b).

To keep pace with changing customer requirements (Mukerjee 2013), a business process has to be improved periodically. Thus, after a certain period of time, a new BPI project is triggered and a new run of the BPI roadmap is initiated. At the beginning of the newly started BPI project, the way the process is currently executed is visualized and the present customer expectations are specified again (Fig. 3). This iterative nature of the BPI roadmap is indicated by the dotted arrow in Fig. 3.

3.3 Design

In the activity “design”, model types to codify the results emerging in BPI projects by applying the roadmap were created. Therefore, each BPI technique was carefully analyzed to preserve its initial functionality. For that purpose, the core concepts of each technique were identified in a first step. For example, the “CTQ/CTB Matrix” holds the core concepts “Voice of Customer (VOC)”, “Voice of Business (VOB)”, “core statement”, “Critical-to-Quality (CTQ) factor” and “Critical-to-Business (CTB) factor” (Meran et al. 2013). The VOCs represent the verbally expressed requirements on the process from a customer’s perspective, e.g., shortened process cycle times. In contrast, the VOBs express the view of employees and the enterprise, e.g., reduced process costs. Similar requirements (VOCs and VOBs) are then classified and so-called core statements are derived. For example, several customer requirements (VOCs) might refer to a higher availability of a company’s call center. These requirements are condensed into a core statement such as “reachability of the call center”. This consolidation process prepares the ground for defining a manageable number of CTQ and CTB factors to be addressed in a BPI initiative.

To arrive at a model type for the “CTQ/CTB Matrix” – called “CTQ/CTB Model” in the following –, a class was defined in the corresponding meta model for each core concept identified (Johannsen and Fill 2016). In a second step, the relations between the core concepts were analyzed in more detail. For example, each of the VOCs and VOBs had to be assigned to one core statement at least. Further, all CTQ and CTB factors must always be related to one or more core statements in addition. Based on those insights, relation types and cardinalities could be defined for the meta model, specifying the interrelations between the classes (Johannsen and Fill 2016).

This procedure was carried out for all techniques of the BPI roadmap, and an integrated meta model as shown in Fig. 4 emerged (Johannsen and Fill 2014a).
Fig. 4

Integrated meta model of the BPI roadmap showing the meta models for each model type of the DSMM as defined (Johannsen and Fill 2014a)

It becomes obvious that the model types have interrelations with one another, so called “inter-model-references (INTERREFs)” indicated as dotted arrows in Fig. 4. This is because the techniques of the BPI roadmap logically build on each other, which was a previously defined requirement (see Table 1 – Rq8 and Rq9). Therefore, results captured in an instance of a model type are referred to by instances of other model types used at later stages of the project. For example, the CTQ and CTB factors as defined in the “CTQ/CTB Model” are referenced by the “Measurement Matrix Model” to assign corresponding KPIs for measuring the goal realization level (see INTERREFs R1 and R2 in Fig. 4).

In total, nine model types were created for the DSMM covering the functionality of all techniques of the BPI roadmap. The statistical techniques of the BPI roadmap, namely histograms, scatterplots and control charts, were considered by the model type “Statistic Interface Model”. This model type relates modeling constructs representing measurement data (e.g., process cycle times) that are stored in a database and referenced correspondingly to the aforementioned analysis techniques. By a coupling to the statistical software “R”,2 the data can then be automatically analyzed to gain valuable insights into the current process performance (e.g., uncovering of variances in process execution times, identification of a rising amount of complaints over the last three months, etc.) and potential problem causes for not reaching the aspired project goals (Fill and Johannsen 2016). For this purpose, the “R” environment is evoked and the data of interest are automatically transferred to corresponding CSV-files, which are analyzed accordingly. Additionally, the “R” software generates graphical representations such as histograms, scatterplots and control charts (Fill and Johannsen 2016). Considering the goals of the project the user thus defines which statistical operations (Fig. 4 – meta model of the “Statistic Interface Model”) to apply on a certain data set (e.g., control chart analysis on a data set “process cycle times”).

Figure 5 exemplifies the linkage of the conceptual model types to the corresponding BPI techniques of the BPI roadmap in excerpts.
Fig. 5

Example of the linkage of model types and techniques of the BPI roadmap emphasizing the types “Measurement Matrix Model”, “CTQ/CTB Model” and “Statistic Interface Model”

The BPI roadmap and the model types help to elicit users’ implicit knowledge of working procedures, including customer requirements or process weaknesses amongst others, and to convert it into explicit process knowledge that can be documented, shared and processed with the purpose of developing solutions for overcoming insufficient process performance. Based on the respective model types, twelve reports were defined capturing the relevant results emerging in a BPI project presenting a descriptive overview of project results once achieved (see Table 2 or Johannsen and Fill 2014a). In the practical application of the BPI roadmap at the automotive bank (see Sect. 3.2), these reports covered all the information that was explicitly asked for by the decision-makers (Johannsen and Fill 2014a).
Table 2

Reports defined on the base of the BPI roadmap and particular model types of the DSMM (see Johannsen and Fill 2014a for more information on the references between meta model classes these reports build on)




Measurement of project goals from a customer perspective

The Critical-to-Quality (CTQ) factors express the customers’ requirements on a process. The report shows which and how many key performance indicators (KPIs) are used for measuring specific project goals (CTQs) derived from customer requirements (VOCs). The goal realization level can be measured accordingly


Measurement of project goals from a business perspective

The Critical-to-Business (CTB) factors characterize project goals from a business perspective. The report indicates which and how many key performance indicators (KPIs) are referred to for measuring certain project goals (CTBs). The CTBs are derived from business requirements (VOBs) accordingly


Organizational data collection report

Specific information on the key performance indicators (KPIs), e.g., on their operational definition, are referred to in the Data Collection Plan Model. This helps to organize the data collection. That way, it is possible to generate a report describing how, when and by whom a key performance indicator (KPI) is collected in a BPI project


Process performance report

The Statistic Interface Model enables the analysis of the process performance. Therefore, the KPIs, are referred to and they are assigned datasets. Reports visualizing the process performance regarding the project goals, e.g., as histograms, can then be established. These reports enable a clear communication of the process performance based on previously defined KPIs


Process problem report

If a process falls short of the project goals, the CTQs and/or CTBs are referred to in the Ishikawa Model. This serves the analysis of problem causes. Reports can be generated which uncover potential problem causes for not reaching certain project goals


Process variance reaction report

The Reaction Plan Model enables a continuous control of the process performance defining which measures are taken in case of unexpected process variances. Therefore, solutions highlighted in the Affinity Model to mitigate process performance variances are suggested to take immediate action


Supplier and input report

The report is generated from a SIPOC Model. It shows which process input (e.g., documents, etc.) is provided by a certain supplier (e.g. car dealer, etc.)


Customer and output report

This report is generated from the SIPOC Model as well. It highlights which output is received by a specific customer (e.g., private customer, etc.)


Project goal definition report

The report provides an overview of which CTQs and CTBs cover the initial statements of the customer (VOCs) and the business (VOBs). The prioritization of project goals is facilitated that way


Performance indicator overview report

This report lists all key performance indicators (KPIs) as defined. Further, it provides an overview regarding their operational definition and the data sources to retrieve the data from


Problem cause report

The report lists the defined problem categories of a process. It also shows the causes (which and how many) that were assigned to each one of them. By that, problem fields can be prioritized much more easily and core problems become obvious


Solution report

The report shows a list of solution categories (e.g., IT, employees, etc.) and corresponding solutions (e.g., introduction of a CRM system, etc.). By that, it is possible to analyze whether solutions have been defined in a one-sided way

3.4 Formalization

To prepare the ground for implementing the BPI roadmap and the DSMM in the form of a modeling tool, the meta models were formalized to receive an implementation-oriented representation. The formalization is a specification of the integrated meta model expressed in a language with a formally defined vocabulary, syntax, semantics and a sound mathematical basis (Fraser et al. 1994).

For that purpose, the FDMM3 formalism was used (Fill et al. 2012), which allows to describe the syntax of meta models and models and the instantiation of models from meta models mathematically. Contrary to other formalization approaches, e.g., EMOF or KM3 (Poernomo 2006; Favre 2010; Jouault and Bézivin 2006), the FDMM formalism has a wide applicability and does not underlie the restrictions of a particular application field, e.g., the description of software structures. Accordingly, formalisms focusing on software structures lack the means of adequately expressing concepts related to BPI (e.g., Voice of the Customer “VOC”) that are represented as classes in the meta model of Fig. 4. Due to its support of various application domains and its ease-of-use, FDMM was chosen as a means for the formalization of the meta models of the BPI roadmap (Johannsen and Fill 2015). Details on the specification of the corresponding meta models via FDMM are described in Johannsen and Fill (2015). The integrated meta model was transformed into FDMM expressions describing the classes, the relations between the classes, the inter-model-references, the attributes’ value ranges or the cardinalities for instance.

Further, the formalization of the meta models served their evaluation prior to the implementation (Fraser et al. 1994). The FDMM representation enabled to check a meta model regarding potential inconsistencies, e.g., the use of implausible cardinalities such as <1,n> instead of <0,n>. In addition, the plausibility of value ranges for attributes could be scrutinized, e.g., the values “time”, “costs”, “flexibility” or “quality” for the attribute “quality dimension”, because the value ranges were to be explicitly defined via FDMM. Additionally, syntactical errors became evident, e.g., in case the meta model part for the CTQ/CTB Matrix model type (Fig. 4) would have allowed to link instances of the class “Voice of the Customer (VOC)” to instances of the class “Critical-to-Quality (CTQ) factor”. Additionally, the completeness of the meta models could be approved because missing cardinalities became obvious and the meta model classes captured in corresponding FDMM expressions were reflected against a BPI technique’s core concepts once again.

Besides the meta models, the reports as presented in Table 2 were formalized (Johannsen and Fill 2015). Figure 6 exemplifies a formalization of the report “project goal definition report” (report #9 in Table 2). By means of this report, it is checked whether all customer requirements (VOCs) were equally considered when defining the CTQ factors or not. In that context, Fig. 6 shows the formalization of the queries required for generating the report, while an excerpt of the report is exemplified below. This example, taken from the cooperation project with the aforementioned automotive bank (Sect. 3.2), uncovers that the CTQ factor “raise the Customer Satisfaction Index (CSI) to a value of 7” subsumes three VOC statements related to unsatisfactory service quality. Therefore, considering the formalization of the queries, all core statements connected with a specific CTQ factor via the connection “Derive-critical-factor” are filtered first (Q1 in Fig. 6) before the VOCs for each core statement are extracted (Q2 in Fig. 6). The queries were tested later on, based on their realization as AQL (ADOxx Query Language) expressions via the corresponding prototype (Sect. 4.1). For that purpose, data stemming from a use case – as described in Sect. 4.1 – was reverted to.
Fig. 6

Example of the “project goal definition report” showing the formalization of the queries required for retrieving the report as well as an excerpt of a corresponding report (extended from Johannsen and Fill 2015)

In summary, on the one hand, the formal FDMM specification and the formal specification of the queries for the reports served as a base for the derivation of implementation-oriented representations to realize the BPI roadmap as a modeling tool. On the other hand, the formalization was essential to assess the consistency, syntactical errors and the completeness of the semi-formal meta model (Fraser et al. 1994).

3.5 Development and Deployment

For realizing a software prototype, we reverted to meta modeling platforms, which strongly support the implementation of a DSMM as a tool requiring little programming efforts only, while an environment for the storage, user interaction and the creation of models is provided automatically (Clark et al. 2008; Karagiannis and Kühn 2002; Johannsen and Fill 2014b). Some representatives of current and commonly known meta modeling platforms are: MetaEdit+ (Tolvanen and Kelly 2009), Eclipse GMF/EMF (McNeill 2008), GME (Ledeczi et al. 2001) and ADOxx (Fill and Karagiannis 2013). To implement the prototype, we chose the ADOxx platform as it has been successfully used in research and practical projects alike for more than 15 years now (Fill and Karagiannis 2013). Additionally, the authors of this paper have efficaciously worked with the platform in both research and practical projects in the recent past.

The ADOxx meta modeling platform is implemented in C++ and enables the easy definition of modeling languages, their graphical representations and required mechanisms and algorithms. Meta models in ADOxx are composed of model types, classes, relationclasses, and attributes (Fill and Karagiannis 2013). That way, the ADOxx meta modeling platform builds on a database-driven, multi-user, client–server repository.

In ADOxx, various domain-specific languages are offered for realizing modeling methods. For instance, ALL (ADOxx Library Language) serves the specification of classes, relationclasses, attributes and model types, whereas their graphical representation is defined by the GRAPHREP language. AQL (ADOxx Query Language) allows to define queries to retrieve information from model instances. Furthermore, the ADOScript language can be used for the implementation of algorithms working on models and for mechanisms on the user interface.

To receive an implementation-oriented representation (ALL and AQL code in our case) that is directly executable on the ADOxx meta modeling platform, the FDMM formalization of the BPI roadmap needed to be enhanced by additional information, e.g., on modeling procedures or algorithms. This was done in the activity “development” (Fig. 2).

Therefore, the meta models as shown in Fig. 4 were transferred to corresponding ALL representations first (Fill et al., 2013). Generally, ALL allows the meta model engineers or method engineers, respectively, to define meta models based on constructs offered by ADOxx (Fill and Karagiannis 2013). The mapping procedure is exemplified in more detail in Johannsen and Fill (2015).

The formalization of the queries (Sect. 3.4) was transferred to executable AQL statements, allowing for the automatic generation of reports based on the information captured in instances of the model types. AQL enables to process queries on model instances to generate reports, similar to the functionality of SQL in the context of databases (Fill and Karagiannis 2013). Selected AQL queries for creating the aforementioned “project goal definition report”, as shown in Fig. 6, are exemplified in Fig. 7.
Fig. 7

Examples of AQL queries for creating the “project goal definition report” based on the formalization as shown in Fig. 6 (Johannsen and Fill 2015)

In the final step “deployment”, the prototypical implementation was transitioned from the development environment into a stand-alone tool, which is provided as an installation package.

Figure 8 shows a screenshot of the prototypical implementation with excerpts from instances of the model types “SIPOC Model” (upper left model), “CTQ/CTB Model” (right model) and “Measurement Matrix Model” (lower left model).
Fig. 8

Screenshot of the implementation as a modeling tool prototype exemplifying instances of the model types “SIPOC Model”, “Measurement Matrix Model” and “CTQ/CTB Model”

4 Evaluation

This chapter describes the evaluation of our implementation of the BPI roadmap resp. the corresponding DSMM as a modeling tool to demonstrate its applicability, its usability and the perceived usefulness in a BPI context (Hevner et al. 2004). The IT-based modeling method (Fill and Karagiannis 2013), consisting of the DSMM and the prototype, targets practitioners who conduct BPI projects and supports the elicitation of implicit process knowledge via BPI techniques, the documentation and communication of the results by conceptual models as well as the further processing of project data (e.g., generation of reports).

For the purpose of evaluation, a use case as well as a usability test are drawn upon. Both evaluation techniques are widely established in the field of modeling method development (Siau and Rossi 2011). Case studies are appreciated for their richness of data emerging and usability tests, in the form of surveys, are generally characterized by a high degree of representativeness (Siau and Rossi 2011).

4.1 Use Case

To demonstrate the applicability of the BPI roadmap and of our implementation for supporting BPI projects, we reverted to data originating from a real world BPI project that had been previously conducted at an automotive bank. The process to be improved was the “End of Terms (EOT)” process, which was an inter-organizational process characterized by explicit customer interfaces and several parties cooperating during process execution (also Fill and Johannsen 2016).

The process worked as follows: each time a customer’s leasing contract for a car ended, the process was triggered. The customer had to return the car to a pre-defined car dealer who calculated the car’s current value with the help of an external assessor who considered all damages or signs of exhaustion. Based on this information, a car return protocol (CRP) was compiled by the car dealer and sent to the automotive bank. The automotive bank then produced the final bill for the customer. As soon as the customer met the bill, the process terminated.

On average, the automotive bank managed about 45,000 expiring leasing contracts each year, with approx. eighteen percent of all cases being transferred to the claims management department. Due to this high amount of data being processed, working errors occurred leading to a high number of complaints (450 per month on average) from the customer side. These errors primarily concerned long processing times for handling ending leasing contracts and calculation errors in the final bills. Additionally, the service quality was criticized as consumers complained about not receiving information they had expected to be provided with by the car dealers or bank employees (e.g., terms for returning the car). On that basis, a BPI project – following the BPI roadmap (Sect. 3.2) – was triggered to reduce the high number of complaints and to restore customer satisfaction.

First, the EOT process was visualized using the “SIPOC Diagram”. Afterwards, the VOCs and VOBs were thoroughly analyzed to precisely specify the CTQ and CTB factors via the “CTQ/CTB Matrix”. The data on VOCs and VOBs originated from the bank’s CRM system, customer and workforce satisfaction studies, interviews with the management, and employees’ experiences gained through the direct interaction with customers. All these sources were analyzed to collect information about customer and employee expectations on process performance. The VOCs and VOBs were then condensed into corresponding CTQ and CTB factors and two major project goals were defined, namely the “reduction of process cycle times” and the “decrease of working errors”. Excerpts from the corresponding “SIPOC Model” and the “CTQ/CTB Model” are shown in Fig. 8 (upper left and right model).

Subsequently, key performance indicators (KPIs) to measure the current process performance in regard to these goals were specified. In this context, typical KPIs were (I) the process cycle time from an end-to-end perspective, (II) the number of customer complaints, (III) the average number of leasing contracts processed each year, (IV) the share of cases transferred to the claims management or (V) the approximate financial value of bills not met by customers then. These KPIs were further decomposed into more specialized KPIs (e.g., cycle times for all sub-processes) resulting in a set of 18 KPIs to be measured in the project. An excerpt from this set, in the form of the model type “Performance Indicator Model”, is shown in Fig. 9. The collection of the measurement data was organized via the “Data Collection Plan” and the data was retrieved from operational IT systems and reports as CSV- and XLS-files. The data could then be automatically analyzed by our tool through a data import interface and a coupling with the statistic software “R” (Fill and Johannsen 2016). For that purpose, the “Statistic Interface Model” type was applied (Fig. 9). As an example, a histogram for the measurement data of the KPI “overall cycle time” (Fig. 9 – Performance Indicator Model) was automatically generated via “R” and handed back to the corresponding instance of the “Statistic Interface Model” as shown in Fig. 9 (data values anonymized).
Fig. 9

Excerpts of the Performance Indicator Model, visualizing the defined KPIs, and the Statistic Interface Model illustrating selected data analyses results

Based on this information, valuable insights into the (current) as-is performance and potential process weaknesses became evident. For example, it turned out that working errors frequently occurred during the transfer of the CRP to the automotive bank. Media disruptions due to the lacking integration of IT systems were seen as a major reason for that. Additionally, many delays when processing leasing contracts were produced by employees laboriously calculating the final bill.

Subsequently, the problem causes for insufficient process performance were systematically collected and structured via the “Ishikawa Diagram”, which served as a base for deriving improvement solutions using the “Affinity Diagram”. One suggestion for improvement was to equip the car dealers with Tablet PCs to automatically distribute data on the car value and the CRP among all process participants. It was further proposed to better integrate the operational IT systems used at the automotive bank and the car dealers. In the end, realizing these proposals led to a significant improvement of the process performance, with working errors more than halved and process cycle times significantly reduced. For instance, the intended timeframe of two working days for calculating the final customer bill on the base of the CRP was met for nearly all ending leasing contracts from then on.

Based on this use case, it became evident that our solution was applicable to process the data emerging in an extensive and inter-organizational BPI project, which did not only refer to the codification of the results as conceptual model types, the logical arrangement of the model types (as indicated by the BPI roadmap), the efficient and automatic analysis of measurement data – by a coupling to the R software –, but also to the automatic generation of reports as shown in Table 2.

4.2 Usability Study

Additionally, the usability of our tool was to be validated from the user perspective. According to literature, usability can be conceived as the “ease-of-use” of a software product and its ability to be applied for the intended purpose (Bevan 1995).

Therefore, a laboratory experiment (Wohlin et al. 2012) was conducted with 28 Master degree students in business administration from an Austrian University. All of these students were attending a course dealing with the fundamentals of process improvement and integrated information systems (IS). The material of the experiment was based on a case study that was designed against the background of the EOT process at the automotive bank as described in Sect. 4.1. Starting with a description of the initial problem setting, the participants were supposed to develop suggestions for overcoming process weaknesses using our software prototype. A pre-test of the material was performed with 20 Master degree students in business informatics at a German University.

To collect the users’ perceptions of the usability of the prototype, the SUMI (Software Usability Measurement Inventory) questionnaire was made use of (Kirakowski and Corbett 1993). The SUMI questionnaire was developed by the Human Factors Research Group (HFRG)4 at the University College Cork and has established as a commonly-accepted approach for testing software usability (Mansor et al. 2012; Fjeld et al. 2007). It was created and validated on a Europe-wide basis (van Veenendaal 1998). The questionnaire builds on 50 different items (e.g., “I feel in command of this software when I am using it”) that allow for assessing the satisfaction of software users according to the dimensions “efficiency”, “affect”, “helpfulness”, “control”, and “learnability“, with Likert-scales being used for rating each item (“agree”, “disagree” and “undecided”) (van Veenendaal 1998). Additionally, a “global scale” was introduced to provide a single construct for the “perceived quality of use” building on 25 selected items providing information on a software’s general usability (van Veenendaal 1998). The major strength of the SUMI approach is that a normative database (comprising approx. 150 software applications) is used for analyzing and interpreting the results gained by applying the SUMI questionnaire (Sauro and Lewis 2012; Cavallin et al. 2007).

In the experiment, the participants were handed out the case study together with the SUMI questionnaire on paper to rate the perceived usability of our software. As SUMI requires the users to have some experience with the tool to be evaluated (van Veenendaal 1998), the students attending the experiment also received an introduction to the prototype with the corresponding training material. Further, they had worked with the tool in the course prior to conducting the actual usability study. For the experiment, the participants were supposed to work on the aforementioned case study on their own and create propositions to improve the performance of the EOT process. More, they could earn extra credits for the course, an incentive to take the experiment seriously (Wohlin et al. 2012). On average, it took the participants 60 min to complete the case study. The solutions were then screened and rated by the course instructor and an additional researcher to eliminate subjectivity. Controversial cases were discussed until a consensus was reached. Contrary to the solutions of the case study, the questionnaires were anonymized and treated independently. This was done to mitigate participants’ concerns about negative consequences resulting from a poor rating of the prototype. Questionnaires or solutions that were incomplete were not further considered for reasons of data validity. In total, 27 solutions and questionnaires were used for the upcoming analysis.5 The data from the questionnaires was entered into the SUMI online form6 and the results of the usability study were made available by the HFRG accordingly. A summary of the results is given in Fig. 10.
Fig. 10

Results of the usability study according to the SUMI dimensions (graphics provided by the HFRG)

Following the SUMI database, the global score (global usability) of a software has an average value of “50” considering a normal distribution whereas the standard deviation is “10” and the maximum score amounts to “73” (Arh and Blažič 2008; van Veenendaal 1998). It turned out that the “global scale” of our prototype was slightly above the aspired value of “50” and thus a positive quality perception from the user side could be observed. Unlike the usability scores for the dimensions “learnability” and “affect”, those for “efficiency” and “helpfulness” were positive regarding the average score of “50” as proposed by the SUMI reference database (van Veenendaal 1998). This suggested that the participants judged the software to be helpful for working on the case study (efficiency) and largely self-explanatory (helpfulness). In that context, a large majority of the participants stated that they would recommend the software for example. More, users generally felt to be in control of the software (control). According to the feedback received, the software did not behave in an unexpected manner when working on the case study. Users’ emotional reaction to the software was average (affect). However, the participants had some concerns regarding the speed of the software and their ability to master the tool and to learn new features (Sauro and Lewis 2012). For example, the participants agreed that there was a lot of reading to be done before they were actually able to work with the software.

All in all, the usability study provided promising results. The global usability of the software was perceived to be above average and its ability to support users in conducting BPI efforts was confirmed against the background of the material of the experiment.

In Sect. 2.1, three major challenges of conducting BPI projects in practice were introduced, namely the (1) rapidly changing customer requirements (e.g., Mukerjee 2013), (2) the efficient codification and documentation of project results and (3) the purposeful selection of BPI techniques to be applied (e.g., Davis 2013). We could show that our solution – the BPI roadmap, the DSMM and the prototype – helps to manage and overcome these challenges. The BPI roadmap was evaluated in several BPI projects at the automotive bank (Sect. 3.2) evidencing that the arrangement of BPI techniques systematically guides employees in conducting BPI projects and supports eliciting process knowledge to be transformed into suggestions for process improvement (challenge 3). More, the BPI roadmap can be repeatedly applied to a business process to align the process design with changing customer needs (challenge 1). Further, the use case and the usability study have proven that the results emerging in a BPI project can be beneficially codified via the DSMM and purposefully documented by means of the prototype (challenge 2).

5 Discussion

In this section, the results of the investigation are summarized and implications for research and practice are discussed.

5.1 Summary of the Results

In this research, we proposed an approach for systematically supporting BPI projects considering current challenges encountered by practitioners when conducting the corresponding initiatives (Sect. 2.1). Generally, the approach builds on two well-established concepts borrowed from knowledge management and IS development, namely “roadmaps” and conceptual modeling (Dalkir 2005; Wand and Weber 2002).

First, the approach consists of the so-called “BPI roadmap”, a conceptual solution for transforming employees’ implicit process knowledge into explicit suggestions for process improvement. Further, software support for applying the roadmap in practice was developed as a modeling tool. For that purpose, meta models were drawn upon to convert the BPI techniques into conceptual model types codifying the results and knowledge emerging in BPI projects. That way, a DSMM for the domain of BPI resulted.

Further, the semi-formal representation of the BPI roadmap as an integrated meta model served as a base for deriving implementation-oriented representations directly executable on meta modeling platforms. In the case at hand, ADOxx was reverted to as a meta modeling platform for realizing the tool, and the implementation-oriented representations took the form of AQL and ALL code.

Thus, the research procedure enabled a smooth transition between the single steps of development, starting with the creation of a conceptual solution for conducting BPI projects to the receipt of a running prototype. The software prototype was evaluated, drawing on a use case and a usability study, based on the SUMI questionnaire.

In so doing, following the paradigm of Design Science (Hevner et al. 2004; Lipton 2010), not only the resulting IT artifact was evaluated but also partial results generated throughout the development process (Sonnenberg and vom Brocke 2012). Therefore, as described in Sect. 3.2, the BPI roadmap served as the subject of evaluation in several BPI projects at an automotive bank. The semi-formal meta model representation was validated by formalizing it by the FDMM approach to receive insights into its consistency, syntactical correctness and completeness as described in Sect. 3.4 (Fraser et al. 1994). Additionally, the implementation of the meta model as a modeling tool served as a proof-of-concept of the BPI roadmap (Hevner et al. 2004). In this context, reverting to meta models and meta modeling platforms proved to be a suitable approach to transfer a conceptual solution in the BPI field into an executable software prototype with functionalities to efficiently codify, communicate, process and analyze emerging project results.

The elements of modeling methods (Karagiannis and Kühn 2002 or Fig. 1) and the functionalities of the underlying technical platform are closely related to one another (Fill and Karagiannis 2013). For instance, the realization of queries to process data captured in instances of model types of a DSMM or algorithms facilitating data interchange between model types (element “mechanisms & algorithms” in Fig. 1) largely depended on the technical platform used and cannot be easily separated from the design of the modeling language (Fill and Karagiannis 2013). Thus, the availability of modeling constructs in a model type strongly affects the proper configuration of queries, e.g., via AQL, amongst others (Fill and Karagiannis 2013). The interdependencies that exist between the design of the modeling language and the technical platform (Fill and Karagiannis 2013) suggest to evaluate the DSMM on the base of its prototypical implementation, which is done in the work at hand.

However, restrictions regarding the evaluation emerged from this procedure, because the DSMM was judged in conjunction with the functionality of the prototype with both perspectives being inseparable from one another. For example, the results for the dimension “efficiency” of the SUMI usability study revealed that users felt well-supported by the software in solving the case study (Sect. 4.2), with the participants not solely rating the applicability of the model types but also the functionalities of the prototype. Thus, additional evaluations for each model type (Sect. 3.3) will have to be done in future. These evaluations will also include the realization of the DSMM using standard software packages.

5.2 Contribution for Research

Different research streams are observed for the BPI discipline. A first research direction, utilizing employees’ process knowledge to eliminate process weaknesses (Seethamraju and Marjanovic 2009), deals with the development of holistic BPI approaches that comprise procedure models structuring a BPI initiative according to particular steps to be performed and techniques supporting a user in creating results (Adesola and Baines 2005; Coskun et al. 2008; Harrington 1991; Povey 1998; Zellner 2011). However, many approaches have methodological flaws complicating their application in BPI projects (Zellner 2011). Another stream of investigation strives for the creation of so-called “BPI patterns” to support the “act of improvement” (Forster 2006) for business processes in particular (Lang et al. 2015). In doing so, the BPI patterns are provided to users as reusable and proven solutions for manually deriving a should-be process design (Lang et al. 2015).

Besides, automatic approaches to identify process weaknesses are increasingly discussed. Therefore, process models are analyzed by tool support and drawbacks of the as-is process become evident (Bergener et al. 2015; Höhenberger and Delfmann 2015). However, these approaches require an adequate process model as input and the implicit knowledge of employees may not be fully exploited when used in isolation. A further topic that has come up in recent years is process mining (van der Aalst et al. 2012) enabling users to compare process instances of the as-is process with an actual should-be process. However, in the case of business processes with a lot of manual activities and lacking IT support, this application is challenging (Leist and Lichtenegger 2010; Lichtenegger 2012).

Considering these research streams, our solution may be assigned to approaches making use of employees’ implicit process knowledge to transform it into beneficial suggestions for process improvement. In this context, helpful insights into research and topics for further work emerged.

First, we transferred established concepts from knowledge management and IS development, namely roadmaps and conceptual modeling, to the field of BPI and created means for systematically conducting BPI projects, considering current challenges in practice at the same time (Sect. 2.1). In doing so, especially the question of how to codify, document and communicate results emerging in projects turned out to be a so far rather under-researched issue in the BPI field. We addressed this question by introducing a DSMM with the corresponding model types as well as tool support, facilitating the analyses of data captured in model instances and the further processing of the results. By that, a new aspect is brought to BPI research streams focusing on the utilization of peoples’ process knowledge. In future work, alternative designs of the model types introduced and their impact on user understandability will be investigated more closely.

Second, it became evident that meta models are an efficient means for identifying interrelationships between BPI techniques guiding their logical arrangement for a BPI initiative. Based on the semi-formal meta model representation, common concepts between BPI techniques emerged by shared classes of the according meta models for instance, which served as an indicator as to whether techniques may positively influence each other during application or not. An example would be the beneficial interplay between the “CTQ/CTB Model” that captures the CTQ and CTB factors of an initiative, which are further processed by the “Measurement Matrix Model” to arrive at KPIs for measuring process performance (Meran et al. 2013).

Future research might deal with the identification of such beneficial synergies between BPI techniques (Bruhn 2013) on a meta model level more closely. Based on that, algorithms can be developed that allow to automatically suggest to the user a set of BPI techniques that may complement a particular technique intended to be applied by the user. That way, the selection of appropriate BPI techniques may be considerably facilitated.

Third, with our implementation and the coupling to the statistical software “R” (Fill and Johannsen 2016), we proposed an approach for joining data analyses and enterprise modeling. Thus, knowledge aspects arising in BPI projects are expressed by instantiating the meta models defined for the BPI roadmap, e.g., an instantiation of the “Measurement Matrix Model” to define KPIs measuring a certain project goal. However, with the “Statistic Interface Model” (Fig. 4), we also introduced a model type that is suitable to represent measurement data collected in BPI projects and the corresponding methods for analyzing these data (e.g., histograms). The analysis is then automatically performed by the R software, and the results are visualized in the model instance of the “Statistic Interface Model”. This is an important contribution to exploiting synergies between enterprise modeling and technology-oriented knowledge management for the purpose of BPI, as these initiatives are usually run independently in companies (McAdam et al. 2014). In future BPI research, it will be investigated more closely as to which extent it is possible to store large amounts of data within databases of meta modeling platforms, and when external storage systems (e.g., separate databases) are required instead.

5.3 Contribution for Practice

Our research provides beneficial means for mitigating particular challenges enterprises currently face when performing BPI projects (Sect. 2.1).

First, as mentioned, practice increasingly abandons holistic methods for BPI (e.g., TQM, Six Sigma) and prefers a manageable set of BPI techniques instead that can be easily applied by employees to improve a company’s business processes (Davis 2013). Nevertheless, the selection and combination of BPI techniques to guide the workforce throughout a BPI project is complicated, as it requires fundamental knowledge in the BPI discipline and in the interrelations between BPI techniques. Therefore, the BPI roadmap presents a valuable contribution as it serves practitioners’ need for workable and easy-to-use BPI approaches. The roadmap builds on a set of well-established BPI techniques that have proven successful in manifold BPI efforts and can be learned quickly in addition, a central requirement of today’s enterprises (Harmon 2016; Gijo et al. 2005). Contrary to BPI techniques developed against the background of a service, e.g., “the seven office sins – value analysis” (Meran et al. 2013), or production setting, e.g., “Poka Yoke” (Meran et al. 2013), the roadmap can be applied in service as well as production industries and does not underlie a branch-specific imprint. The techniques of the BPI roadmap logically build on each other, which means that results created by a particular BPI technique are taken up to be further processed by another one. This helps to avoid inconsistency of the results produced throughout a project.

Second, the efficient communication of results is decisive, which is not only relevant for a firm’s internal projects but also particularly important for inter-organizational BPI efforts to avoid rework and undoing results once achieved (Breyfogle 2010; Samson and Challis 2002). In this context, the research at hand introduces a DSMM comprising corresponding model types to codify the results created in a BPI initiative with conceptual modeling being an effective and widely-accepted approach for documenting knowledge in practice (Anaby-Tavor et al. 2010; Davies et al. 2006). Additionally, by our software prototype, beneficial reports (Table 2) can be automatically created, structuring the data captured in the respective instances of the model types. More, the results documented via the software prototype may be accessed by all project participants – even across company boarders – through the realization as a client–server architecture. Therefore, the proper documentation, processing and communication of the results of a BPI initiative are substantially facilitated, thus strongly contributing to an adequate coordination of BPI projects.

Third, the rapidly changing customer requirements, especially in the service sector, make it difficult for firms to keep pace with consumers’ current needs (Bruhn 2013; Greenberg 2010; Lewis 2007; Mukerjee 2013). Indeed, this is one of the most complex issues staff in charge of BPI have to deal with as it cannot be mitigated by method-oriented solutions alone, but also requires organizational changes regarding the frequency of conducting BPI projects. Considering this, two aspects need to be acknowledged: first, BPI initiatives should apply BPI techniques that explicitly take the VOCs and VOBs into consideration for deriving project goals and improvement opportunities. Otherwise, the projects are likely to fail at realizing changes that are in accordance with customer and employee expectations (Breyfogle 2010; Chakravorty 2010). The BPI roadmap explicitly takes this issue into account as the VOCs and VOBs are taken as a base for formulating CTQ and CTB factors – via the “CTQ/CTB Matrix” – right at the beginning of a project. The results produced by applying the subsequent BPI techniques of the roadmap refer to these CTQ and CTB factors – due to complementary interdependencies between the techniques –, which assures that the improvement suggestions are developed against the background of customers’ and employees’ requirements. As a second aspect, BPI projects must be performed continuously. This requires a firm to ensure the necessary management commitment and availability of human resources (Chakrabarty and Tan 2007), which are, however, topics that are beyond the immediate influence of our research. Nevertheless, our solution strongly supports the continuous improvement of a process, as results are seamlessly documented in the software database and may be efficiently referred to in subsequent projects. Further, the coupling of our prototype to the statistic software “R” allows to rapidly analyze measurement data and monitor the process performance over a given period of time. In addition, the reuse of certain results, e.g., KPIs, across projects is fostered. These features contribute to the efficient execution of BPI projects at regular intervals thus supporting continuous process improvement.

6 Conclusion and Outlook

Starting with the introduction of challenges of purposefully conducting BPI projects, the BPI roadmap, a DSMM and a corresponding software prototype were developed. Throughout this development, semi-formal and implementation-oriented representations were drawn upon to transfer a conceptual solution into a running prototype using a meta modeling platform. The solution was evaluated and proved applicable to systematically support BPI projects, mitigating current challenges.

Several benefits for practice emerged, which concerned the purposeful execution of BPI efforts addressing issues such as the efficient codification, communication and analyses of results. Further contributions for research were achieved, e.g., by joining conceptual modeling and data analyses or highlighting the beneficial role of meta models for developing solutions for a BPI setting.

However, there are also some limitations to this study: the BPI roadmap has so far only been evaluated in BPI projects of an automotive bank. Further evaluations in small and medium-sized companies across industries are currently being performed. The BPI roadmap does not underlie a branch-specific imprint and its techniques are suitable for both service and production settings, assuring its inter-sectoral usability. Further, completeness in terms of requirements concerning the BPI roadmap cannot be guaranteed. However, to reach a general validity, literature was drawn upon in that context. The SUMI usability study was performed with Master degree students, which also is a limitation. Therefore, a corresponding study with practitioners is an open issue to be addressed. Furthermore, the design of the model types was derived from a thorough analysis of the underlying functionality of the BPI techniques considered. Nevertheless, the graphical representation of the modeling constructs was not explicitly evaluated during the design but was only subjected to evaluation in our usability study.

Several topics for future work have emerged: first, we will further evaluate our prototype in usability studies including practitioners but also in real-life BPI projects with companies of different sizes and across branches. The prototype’s contribution to supporting the elicitation of process knowledge, the analysis of process data and the documentation of project results is to be precisely assessed for cases, in addition to the one previously described (Sect. 4.1). Project participants will be asked to complete the SUMI questionnaire to rate the software on the base of the five dimensions as introduced in Sect. 4.2. Thus, opportunities for the advancement of the prototype will emerge, possibly concerning the incorporation of more explanatory information supporting the user during the interaction with the tool or a visual redesign of the model types and modeling elements. Second, we will investigate more closely how BPI approaches building on employees’ knowledge can be integrated with automatic analyses of process representations in a BPI initiative (Sect. 5.2). For example, automatic approaches may be embedded into projects building on employees’ process knowledge in project stages explicitly focusing on deriving problem causes. Third, it needs to be explored in greater detail to which extent big data (e.g., data records of measurement data on process cycle times or of customer requirements “VOCs” exported from CRM systems) characterized by a high volume, velocity, variety and veracity (McAfee and Brynjolfsson 2012) can be stored in our prototype directly or when external storage is required. Generally, an own database is provided by our prototype to hold process data, whereas the distributed storage of extensive data sets, e.g., via Apache Hadoop, is also supported by the R platform (Fill and Johannsen 2016).


  1. 1.

    Details on each BPI technique can be found in Hagemeyer et al. (2006); Griesberger et al. (2011); Meran et al. (2013); George et al. (2005); Pande et al. (2000), or Kettinger et al. (1997) for instance.

  2. 2.; accessed 22 July 2016.

  3. 3.

    Formalism for Describing ADOxx Meta Models and Models.

  4. 4.
  5. 5.

    According to the HFRG, a minimum number of 10–12 participants is required to arrive at a valid analysis.

  6. 6.; Accessed 22 July 2016.


  1. Adesola S, Baines T (2005) Developing and evaluating a methodology for business process improvement. Bus Process Manag J 11(1):37–46CrossRefGoogle Scholar
  2. Anaby-Tavor A, Amid D, Fisher A, Bercovici A, Ossher H, Callery M, Desmond M, Krasikov S, Simmonds I (2010) Insights into enterprise conceptual modeling. Data Knowl Eng 69(12):1302–1318CrossRefGoogle Scholar
  3. Andersen B (1999) Business process improvement toolbox. ASQ Qual Press, MilwaukeeGoogle Scholar
  4. Angele J, Fensel D, Landes D, Studer R (1998) Developing knowledge-based systems with MIKE. Autom Softw Eng 5(4):389–418CrossRefGoogle Scholar
  5. Arh T, Blažič BJ (2008) A case study of usability testing – the SUMI evaluation approach of the EducaNext portal. WSEAS Trans Inf Sci Appl 5(2):175–181Google Scholar
  6. Balestracci D (2009) Why did total quality management fail? Quality Digest. Accessed 17 May 2017
  7. Bamford D, Greatbanks R (2005) The use of quality management tools and techniques: a study of application in everyday situations. Int J Qual Reliab Manag 22(4):376–392CrossRefGoogle Scholar
  8. Becker J, Kahn D (2012) Der Prozess im Fokus. In: Becker J, Kugeler M, Rosemann M (eds) Prozessmanagement - Ein Leitfaden zur prozessorientierten Organisationsgestaltung, 7th edn. Springer, Heidelberg, pp 1–16Google Scholar
  9. Bergener P, Delfmann P, Weiss B, Winkelmann A (2015) Detecting potential weaknesses in business processes: an exploration of semantic pattern matching in process models. Bus Process Manag J 21(1):25–54CrossRefGoogle Scholar
  10. Bevan N (1995) Measuring usability as quality of use. Softw Qual J 4(2):115–130CrossRefGoogle Scholar
  11. Bork D, Fill H-G (2014) Formal aspects of enterprise modeling methods: a comparison framework. In: Proceedings of 47th Hawaii International Conference on System Sciences (HICSS), Waikoloa, Hawaii, pp 3400–3409Google Scholar
  12. Breyfogle FW (2010) Process improvement projects shortcomings and resolution. Int J Lean Six Sigma 1(2):92–98CrossRefGoogle Scholar
  13. Bruhn M (2013) Operative Gestaltung des Qualitätsmanagements für Dienstleistungen. In: Bruhn M (ed) Qualitätsmanagement für Dienstleistungen, 9th edn. Springer, Heidelberg, pp 251–354CrossRefGoogle Scholar
  14. Bunney HS, Dale BG (1997) The implementation of quality management tools and techniques: a study. TQM Mag 9(3):183–189CrossRefGoogle Scholar
  15. Cavallin H, Martin WM, Heylighen A (2007) How relative absolute can be: SUMI and the impact of the nature of the task in measuring perceived software usability. AI Soc 22(2):227–235CrossRefGoogle Scholar
  16. Chakrabarty A, Tan KC (2007) The current state of six sigma application in services. Manag Service Qual 17(2):194–208CrossRefGoogle Scholar
  17. Chakravorty SS (2010) Where process-improvement projects go wrong. Wall Street J. Accessed 17 May 2017
  18. Clark T, Sammut P, Willans J (2008) Applied metamodelling: a foundation for language driven development. Accessed 29 Apr 2017
  19. Coskun S, Basligil H, Baracli H (2008) A weakness determination and analysis model for business process improvement. Bus Process Manag J 14(2):243–261CrossRefGoogle Scholar
  20. Dale BG, McQuater R (1998) Managing business improvement & quality: implementing key tools and techniques. Blackwell Business, OxfordGoogle Scholar
  21. Dalkir K (2005) Knowledge management in theory and practice. McGill University, AmsterdamGoogle Scholar
  22. Davies I, Green P, Rosemann M, Indulska M, Gallo S (2006) How do practitioners use conceptual modeling in practice? Data Knowl Eng 58(3):358–380CrossRefGoogle Scholar
  23. Davis D (2013) 3rd biennial PEX network report: state of the industry – trends and success factors in business process excellence.
  24. de Mast J (2004) A methodological comparison of three strategies for quality improvement. Int J Qual Reliab Manag 21(2):198–213CrossRefGoogle Scholar
  25. Erdani Y, Hunger A, Werner S, Mertens S (2004) Ternary grid as a potentially new technique for knowledge elicitation/acquisition. In: Proceedings of 2nd International IEEE Conference on Intelligent Systems, 2004. IEEE, pp 312–315Google Scholar
  26. Favre LM (2010) Formalization of MOF-based metamodels. In: Favre LM (ed) Model driven architecture for reverse engineering technologies. Information Resources Management Association. pp 49–79Google Scholar
  27. Feller J, Parhankangas A, Smeds R, Jaatinen M (2013) How companies learn to collaborate: emergence of improved inter-organizational processes in R&D alliances. Organ Stud 34(3):313–343CrossRefGoogle Scholar
  28. Fill H-G (2012) SeMFIS: A tool for managing semantic conceptual models. In: Workshop on graphical modeling language development, Lyngby, DenmarkGoogle Scholar
  29. Fill H-G (2016) SeMFIS: a flexible engineering platform for semantic annotations of conceptual models. Accepted for Semantic Web – Interoperability, Usability, Applicability. doi:10.3233/SW-160235
  30. Fill H-G, Johannsen F (2016) A knowledge perspective on big data by joining enterprise modeling and data analyses. In: Proceedings of 49th Hawaii International Conference on System Sciences (HICSS), Kauai, Hawaii, pp 405–4061Google Scholar
  31. Fill H-G, Karagiannis D (2013) On the conceptualisation of modelling methods using the ADOxx meta modelling platform. Enterp Model Inf Syst Archit 8(1):4–25CrossRefGoogle Scholar
  32. Fill H-G, Redmond T, Karagiannis D (2012) FDMM: a formalism for describing ADOxx meta models and models. In: Maciaszek, L., Cuzzocrea, A., Cordeiro, J. (eds) Proceedings of ICEIS 2012 – 14th International Conference on Enterprise Information Systems, SciTePress, Vol.3, pp.133–144Google Scholar
  33. Fill H-G, Redmond T, Karagiannis D (2013) Formalizing meta models with FDMM: the ADOxx case. In: Cordeiro J, Maciaszek L, Filipe J (eds) Enterprise information systems LNBIP, vol 141. Springer, Berlin, pp 429–451CrossRefGoogle Scholar
  34. Fjeld M, Fredriksson J, Ejdestig M, Duca F, Bötschi K, Voegtli B, Juchli P (2007) Tangible user interface for chemistry education: comparative evaluation and re-design. In: Proceedings SIGCHI Conference on human factors in computing systems, ACM, pp 805–808Google Scholar
  35. Forster F (2006) The idea behind business process improvement: toward a business process improvement pattern framework. BPTrends 2006:1–13Google Scholar
  36. Frank U (2010) Outline of a method for designing domain-specific modelling languages. ICB-Research Report, No. 42Google Scholar
  37. Frank U (2011a) Some guidelines for the conception of domain-specific modelling languages. In: Nuettgens M, Thomas O, Weber B (eds) Proceedings of the EMISA, Vol. 2011. GI, pp 93–106Google Scholar
  38. Frank U (2011b) The MEMO meta modelling language (MML) and language architecture. ICB-Research Report, No, p 43Google Scholar
  39. Frank U, Heise D, Kattenstroth H, Schauer H (2008) Designing and utilising business indicator systems within enterprise models-outline of a method. Proc MobIS 2008:89–105Google Scholar
  40. Fraser MD, Kumar K, Vaishnavi VK (1994) Strategies for incorporating formal specifications in software development. Commun ACM 37(10):74–86CrossRefGoogle Scholar
  41. George ML, Rowlands D, Price M, Maxey J (2005) Lean six sigma pocket toolbox. McGraw-Hill, New YorkGoogle Scholar
  42. Gijo EV, Rao TS (2005) Six sigma implementation – hurdles and more hurdles. Total Qual Manag Bus Excell 16(6):721–725CrossRefGoogle Scholar
  43. Gray J, Tolvanen J-P, Kelly S, Gokhale A, Neema S, Sprinkle J (2007) Domain-specific modeling. Handb Dyn Syst Model 7:1–7Google Scholar
  44. Greenberg P (2010) The impact of CRM 2.0 on customer insight. J Bus Indust Market 25(6):410–419CrossRefGoogle Scholar
  45. Gregor S, Hevner AR (2013) Positioning and presenting design science research for maximum impact. MIS Q 37(2):337–356Google Scholar
  46. Griesberger P, Leist S, Zellner G (2011) Analysis of techniques for business process improvement. In: Proceedings 19th European Conference on Information Systems (ECIS 2011), HelsinkiGoogle Scholar
  47. Gutzwiller TA (1994) Das CC RIM-Referenzmodell für den Entwurf von betrieblichen, transaktionsorientierten Informationssystemen. Physica, HeidelbergCrossRefGoogle Scholar
  48. Hagemeyer C, Gershenson JK, Johnson DM (2006) Classification and application of problem solving quality tools: a manufacturing case study. TQM Mag 18(5):455–483CrossRefGoogle Scholar
  49. Hall M (2006) Knowledge management and the limits of knowledge codification. J Knowl Manag 10(3):117–126CrossRefGoogle Scholar
  50. Hanif M, Khan YS, Zaheer A (2014) Impact of organizational resistance to change on BPR implementation: a case of State Bank of Pakistan. Eur J Bus Manag 6(4):186–196Google Scholar
  51. Harel D, Rumpe B (2000) Modeling languages: syntax, semantics and all that stuff, Part I: the basic stuff. Technical Report MCS00-16Google Scholar
  52. Harel D, Rumpe B (2004) Meaningful modeling: what's the semantics of "semantics"? IEEE Computer 37(10):64–72Google Scholar
  53. Harmon P (2016) The state of business process management – 2016. a BPTrends report. Accessed 17 May 2017
  54. Harrington HJ (1991) Business process improvement - the breakthrough strategy for total quality, productivity and competitiveness. McGraw-Hill, New YorkGoogle Scholar
  55. Harrington HJ, Lomax KC (2000) Performance improvement methods: fighting the war on waste. McGraw-Hill, New YorkGoogle Scholar
  56. Heckl D, Moormann J, Rosemann M (2010) Uptake and success factors of Six Sigma in the financial services industry. Bus Process Manag J 16(3):436–472CrossRefGoogle Scholar
  57. Hevner AR, March ST, Park J, Ram S (2004) Design science in information systems research. MIS Q 28(1):75–105Google Scholar
  58. Höfferer P (2007) Achieving business process model interoperability using metamodels and ontologies. In: Österle H, Schelp J, Winter R (eds) 15th European Conference on Information Systems, St. Gallen, pp 1620–1631Google Scholar
  59. Höhenberger S, Delfmann P (2015) Supporting business process improvement through business process weakness pattern collections. In: Proceedings 12th International Conference on Wirtschaftsinformatik, OsnabrückGoogle Scholar
  60. Ishikawa K (1980) Guide to quality control. Asian Productivity Organization, TokyoGoogle Scholar
  61. Johannsen F (2011) State of the art concerning the integration of methods and techniques in quality management – literature review and an agenda for research. In: Proceedings of 19th European Conference on Information Systems (ECIS), HelsinkiGoogle Scholar
  62. Johannsen F, Fill H-G (2014a) Codification of knowledge in business process improvement projects. In: Proceeding of 22nd European Conference on Information Systems, Tel AvivGoogle Scholar
  63. Johannsen F, Fill H-G (2014b) RUPERT: a modelling tool for supporting business process improvement initiatives. In: Tremblay MC, Van der Meer D, Rothenberger M, Gupta A, Yoon V (eds) 9th International Conference on Design Science Research in Information Systems and Technology (DESRIST), Miami, Springer, pp 418–422Google Scholar
  64. Johannsen F, Fill H-G (2015) Supporting knowledge elicitation and analysis for business process improvement through a modeling tool. In: Proceedings 12th International Conference on Wirtschaftsinformatik, OsnabrückGoogle Scholar
  65. Johannsen F, Fill H-G (2016) Supporting business process improvement through a modeling tool. In: Karagiannis D, Mayr CH, Mylopoulos J (eds) Domain-specific conceptual modeling. Springer, Heidelberg, pp 217–237CrossRefGoogle Scholar
  66. Johannsen F, Leist S, Zellner G (2015) Implementing Six Sigma for improving business processes at an automotive bank. In: Vom Brocke J, Rosemann M (eds) Handbook on business process management 1, 2nd edn. Springer, Heidelberg, pp 361–382Google Scholar
  67. Jouault F, Bézivin J (2006) KM3: a DSL for metamodel specification. In: Proceedings International Conference on Formal Methods for Open Object-Based Distributed Systems. Springer, pp 171–185Google Scholar
  68. Kaplan AM, Haenlein M (2010) Users of the world, unite! The challenges and opportunities of social media. Bus Horizons 53(1):59–68CrossRefGoogle Scholar
  69. Karagiannis D, Kühn H (2002) Metamodelling platforms. In: Bauknecht K, Min Tjoa A, Quirchmayr G (eds) Proceedings 3rd International Conference EC-Web 2002 - Dexa 2002, Aix-en-Provence, pp 182–195Google Scholar
  70. Karagiannis D, Grossmann W, Höfferer P (2008) Open model initiative: a FEASIBILITY study. University of Vienna, Department of Knowledge Engineering, ViennaGoogle Scholar
  71. Kettinger WJ, Teng JTC, Guha S (1997) Business process change: a study of methodologies, techniques, and tools. MIS Q 21(1):55–80CrossRefGoogle Scholar
  72. Kirakowski J, Corbett M (1993) SUMI: the software usability measurement inventory. Br J Educ Technol 24(3):210–212CrossRefGoogle Scholar
  73. Klefsjö B, Bergquist B, Garvare R (2008) Quality management and business excellence, customers and stakeholders: do we agree on what we are talking about, and does it matter? TQM J 20(2):120–129CrossRefGoogle Scholar
  74. Koubarakis M, Plexousakis D (1999) Business process modelling and design – a formal model and methodology. BT Technol J 17(4):23–35CrossRefGoogle Scholar
  75. Kühne T (2006) Matters of (meta-) modeling. J Softw Syst Model 5(4):369–385CrossRefGoogle Scholar
  76. Lang M, Wehner B, Falk T, Griesberger P, Leist S (2015) Evaluating business process improvement patterns by simulation. In: Proceedings 23rd European Conference on Information Systems (ECIS 2015), MünsterGoogle Scholar
  77. Le Dinh T, Rickenberg TA, Fill HG, Breitner MH (2014) Towards a knowledge-based framework for enterprise content management. In: Proceedings 47th Hawaii International Conference on System Sciences (HICSS)Google Scholar
  78. Ledeczi A, Maroti M, Bakay A, Karsai G, Garrett J, Thomason C, Nordstrom G, Sprinkle J, Volgyesi P (2001) The generic modeling environment. In: Proceedings of the Workshop on Intelligent Signal Processing, Budapest, HungaryGoogle Scholar
  79. Lee KT, Chuah KB (2001) A SUPER methodology for business process improvement. Int J Oper Prod Manag 21(5/6):687–706CrossRefGoogle Scholar
  80. Leist S, Lichtenegger W (2010) Integration von automatisch generierten und manuell konstruierten Prozessmodellen als Grundlage für den Aufbau einer Prozessarchitektur. In: Proceedings Multikonferenz Wirtschaftsinformatik, GöttingenGoogle Scholar
  81. Lewis BR (2007) Managing service quality. In: Dale BG, van der Wiele T, van Iwaarden J (eds) Managing quality. Blackwell, Malden, pp 234–257Google Scholar
  82. Lichtenegger W (2012) Methoden zur teilautomatischen Konstruktion von Ist-Prozessmodellen mittels Process Mining sowie zur Integration manuell konstruierter und automatisch generierter Ist-Prozessmodelle. Logos, BerlinGoogle Scholar
  83. Lipton P (2010) Engineering and Truth. In: The Royal Academy of Engineering: Philosophy of engineering - Volume 1 of the proceedings of a series of seminars held at The Royal Academy of Engineering, pp 7–13Google Scholar
  84. Lovelock C, Wirtz J (2011) Services marketing - people, technology, strategy, 7th edn. Pearson, SingaporeGoogle Scholar
  85. Low WZ, van den Broucke SKLM, Wynn MT, ter Hofstede AHM, De Weerdt J, van der Aalst WMP (2015) Revising history for cost-informed process improvement. Comput 1–27Google Scholar
  86. Lymperopoulos C, Chaniotakis IE, Soureli M (2013) The role of price satisfaction in managing customer relationships: the case of financial services. Market Intell Plan 31(3):216–228CrossRefGoogle Scholar
  87. Magnusson K, Kroslid D, Bergman B (2004) Six Sigma umsetzen, 2nd edn. Hanser, MünchenGoogle Scholar
  88. Mansor Z, Kasirun ZM, Yahya S, Arshad NH (2012) The evaluation of WebCost using Software Usability Measurement Inventory (SUMI). Int J Digit Inf Wireless Commun (IJDIWC) 2(2):197–201Google Scholar
  89. McAdam R, Antony J, Kumar M, Hazlett SA (2014) Absorbing new knowledge in small and medium-sized enterprises: a multiple case analysis of Six Sigma. Int Small Bus J 32(1):81–109CrossRefGoogle Scholar
  90. McAfee A, Brynjolfsson E (2012) Big data: the management revolution. Harv Bus Rev 90(10):60–66Google Scholar
  91. McDonald MP, Aron D (2011) Executive summary: reimagining IT: the 2011 CIO agenda. Gartner ResearchGoogle Scholar
  92. McNeill K (2008) Metamodeling with EMF: Generating concrete, reusable Java snippets. Accessed 26 Jan 2016
  93. McQuater RE, Scurr CH, Dale BG, Hillmann PG (1995) Using quality tools and techniques successfully. TQM Mag 7(6):37–42CrossRefGoogle Scholar
  94. Mellat-Parast M (2013) Supply chain quality management: an inter-organizational learning perspective. Int J Qual Reliab Manag 30(5):511–529CrossRefGoogle Scholar
  95. Meran R, John A, Roenpage O, Staudter C (2013) Six Sigma + Lean toolset. Springer, HeidelbergCrossRefGoogle Scholar
  96. Mukerjee K (2013) Customer-oriented organizations: a framework for innovation. J Bus Strateg 34(3):49–56CrossRefGoogle Scholar
  97. Mylopoulos J (1992) Conceptual modeling and Telos. In: Loucopoulos P, Zicari R (eds) Conceptual modelling, databases and CASE: an integrated view of information systems development. Wiley, Hoboken, pp 49–68Google Scholar
  98. Object Management Group OMG (2015): OMG Unified Modeling Language TM (OMG UML) – version 2.5. Accessed 25 May 2016
  99. Okes D (2002) Organize your quality tool belt. Qual Progress (July 2002), pp.82–86Google Scholar
  100. Pande P, Neumann R, Cavanagh R (2000) The Six Sigma way - how GE, Motorola and other top companies are honing their performance. McGraw Hill, New YorkGoogle Scholar
  101. Persson A (2013) Profitable customer management: reducing costs by influencing customer behaviour. Europ J Market 47(5/6):857–876CrossRefGoogle Scholar
  102. Poernomo I (2006) The meta-object facility typed. In: Proceedings of the 2006 ACM symposium on Applied computing. ACM, pp 1845–1849Google Scholar
  103. Povey B (1998) The development of a best practice business process improvement methodology. Benchmarking 5(1):27–44Google Scholar
  104. Psomas EL, Fotopoulos CV, Kafetzopoulos DP (2011) Core process management practices, quality tools and quality improvement in ISO 9001 certified manufacturing companies. Bus Process Manag J 17(3):437–460CrossRefGoogle Scholar
  105. Rafferty AE, Jimmieson NL, Armenakis AA (2013) Change readiness. A Multilevel Review. J Manag 39(1):110–135Google Scholar
  106. Rigby D, Bilodeau B (2015) Management tools & trends 2015. Bain & Company, BostonGoogle Scholar
  107. Samson D, Challis D (2002) Patterns of business excellence. Meas Bus Excell 6(2):15–21CrossRefGoogle Scholar
  108. Sarkar B, Moon I (2014) Improved quality, setup cost reduction, and variable backorder costs in an imperfect production process. Int J Prod Econ 155(2014):204–213CrossRefGoogle Scholar
  109. Sauro J, Lewis JR (2012) Quantifying the user experience: practical statistics for user research. Elsevier, AmsterdamGoogle Scholar
  110. Scheer A-W, Schneider K (2006) ARIS - architecture of integrated information systems. In: Bernus P, Mertins K, Schmidt G (eds) International handbooks on information systems - Part three. Springer, Heidelberg, pp 605–623Google Scholar
  111. Schönthaler F, Vossen G, Oberweis A, Karle T (2012) The Horus method. Business processes for business communities. Springer, Heidelberg, pp 61–136CrossRefGoogle Scholar
  112. Seethamraju R, Marjanovic O (2009) Role of process knowledge in business process improvement methodology: a case study. Bus Process Manag J 15(6):920–936CrossRefGoogle Scholar
  113. Shamma H, Hassan S (2013) Customer-driven benchmarking: a strategic approach toward a sustainable marketing performance. Benchmarking 20(3):377–395CrossRefGoogle Scholar
  114. Siau K, Rossi M (2011) Evaluation techniques for systems analysis and design modelling methods – a review and comparative analysis. Inf Syst J 21(3):249–268CrossRefGoogle Scholar
  115. Snee R, Hoerl R (2003) Leading Six Sigma. Prentice Hall, New YorkGoogle Scholar
  116. Sonnenberg C, vom Brocke J (2012) Evaluations in the science of the artificial – reconsidering the build-evaluate pattern in design science research. In: Peffers K, Rothenberger M, Kuechler B (eds) Design science research in information systems,Advances in theory and practice. Springer, Heidelberg, pp 381–397CrossRefGoogle Scholar
  117. Strahringer S (1996) Metamodellierung als Instrument des Methodenvergleichs. Shaker, AachenGoogle Scholar
  118. Strecker S, Heise D, Frank U (2011) RiskM: a multi-perspective modeling method for IT risk assessment. Inf Syst Front 13(4):595–611CrossRefGoogle Scholar
  119. Studer R, Benjamins VR, Fensel D (1998) Knowledge engineering: principles and methods. Data Knowl Eng 25(1):161–197CrossRefGoogle Scholar
  120. Telang PR, Singh MP (2012) Specifying and verifying cross-organizational business models: an agent-oriented approach. IEEE Trans Services Comput 5(3):305–318CrossRefGoogle Scholar
  121. Thalheim B (2010) Towards a theory of conceptual modelling. J Univers Comput Sci 16(20):3102–3137Google Scholar
  122. Thia C, Chai KH, Bauly J, Xin Y (2005) An exploratory study of the use of quality tools and techniques in product development. TQM Mag 17(5):406–424CrossRefGoogle Scholar
  123. Todnem By R (2005) Organisational change management: a critical review. J Change Manag 5(4):369–380CrossRefGoogle Scholar
  124. Tolvanen J-P, Kelly S (2009) MetaEdit+: defining and using integrated domain-specific modeling languages. In: Proceedings of the 24th ACM SIGPLAN conference companion on Object oriented programming systems languages and applications. ACM, pp 819–820Google Scholar
  125. Turber S, vom Brocke J, Gassmann O, Fleisch E (2014) Designing business models in the era of internet of things. In: Proceedings 9th International Conference on Design Science Research in Information Systems and Technology. Springer, pp 17–31Google Scholar
  126. Turkyilmaz A, Oztekin A, Zaim S, Demirel OF (2013) Universal structure modeling approach to customer satisfaction index. Indust Manag Data Syst 113(7):932–949CrossRefGoogle Scholar
  127. van der Aalst W, Adriansyah A, de Medeiros AKA, Arcieri F, Baier T, Blickle T, Bose JC, van den Brand P, Brandtjen R, Buijs J (2012) Process mining manifesto. Proceedings of the business process management workshops, lecture notes in business information processing, vol 99. Springer, Heidelberg, pp 169–194Google Scholar
  128. van Veenendaal E (1998) Questionnaire based usability testing. In: Proceedings European Software Quality Week Conference, BrusselsGoogle Scholar
  129. vom Brocke J, Schmiedel T, Recker J, Trkman P, Mertens W, Viaene S (2014) Ten principles of good business process management. Bus Process Manag J 20(4):530–548CrossRefGoogle Scholar
  130. Wand Y, Weber R (2002) Research commentary: information systems and conceptual modeling – a research agenda. Inf Syst Research 13(4):363–376CrossRefGoogle Scholar
  131. Weber RH, Weber R (2010) Internet of things. Springer, HeidelbergCrossRefGoogle Scholar
  132. Wohlin C, Runeson P, Höst M, Ohlsson MC, Regnell B, Wesslén A (2012) Experimentation in software engineering. Springer, HeidelbergCrossRefGoogle Scholar
  133. Womack JP, Jones DT (1996) Lean thinking. Simon & Schuster, New YorkGoogle Scholar
  134. Womack J, Jones D, Roos D (2007) The machine that changed the world, 2nd edn. Free Press, New YorkGoogle Scholar
  135. Xu Y, Bernard A, Perry N, Lian L (2011) Managing knowledge management tools: a systematic classification and comparison. In: IEEE Proceedings International Conference on Management and Service ScienceGoogle Scholar
  136. Nayatani Y (1986) Seven management tools for QC. Rep Stat Appl Res JUSE 33(2):1–6Google Scholar
  137. Zellner G (2011) A structured evaluation of business process improvement approaches. Bus Process Manag J 17(2):203–237CrossRefGoogle Scholar
  138. Zu X (2009) Infrastructure and core quality management practices: how do they affect quality? Int J Qual Reliab Manag 26(2):129–149CrossRefGoogle Scholar

Copyright information

© Springer Fachmedien Wiesbaden 2017

Authors and Affiliations

  1. 1.Department of Management Information SystemsUniversity of RegensburgRegensburgGermany
  2. 2.Information Systems – System Development and Database Application GroupUniversity of BambergBambergGermany

Personalised recommendations