Meta Modeling for Business Process Improvement
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.
KeywordsBusiness 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).
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
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 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
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).
Requirements on the roadmap (Johannsen and Fill 2014a)
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).
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.
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).
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”).
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
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
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.
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).
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.
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).
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).
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).
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).
https://www.r-project.org/; accessed 22 July 2016.
Formalism for Describing ADOxx Meta Models and Models.
http://www.ucc.ie/hfrg/questionnaires/sumi/index.html; Accessed 22 July 2016.
According to the HFRG, a minimum number of 10–12 participants is required to arrive at a valid analysis.
http://sumi.ucc.ie/en/; Accessed 22 July 2016.
- Andersen B (1999) Business process improvement toolbox. ASQ Qual Press, MilwaukeeGoogle Scholar
- 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
- Balestracci D (2009) Why did total quality management fail? Quality Digest. https://www.qualitydigest.com/inside/twitter-ed/why-did-total-quality-management-fail.html#. Accessed 17 May 2017
- 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
- 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
- Chakravorty SS (2010) Where process-improvement projects go wrong. Wall Street J. https://www.wsj.com/articles/SB10001424052748703298004574457471313938130. Accessed 17 May 2017
- Clark T, Sammut P, Willans J (2008) Applied metamodelling: a foundation for language driven development. http://shura.shu.ac.uk/11884/. Accessed 29 Apr 2017
- Dale BG, McQuater R (1998) Managing business improvement & quality: implementing key tools and techniques. Blackwell Business, OxfordGoogle Scholar
- Dalkir K (2005) Knowledge management in theory and practice. McGill University, AmsterdamGoogle Scholar
- Davis D (2013) 3rd biennial PEX network report: state of the industry – trends and success factors in business process excellence. http://www.processexcellencenetwork.com/business-transformation/white-papers/special-report-trends-and-success-factors-in-busin
- 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
- 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
- Fill H-G (2012) SeMFIS: A tool for managing semantic conceptual models. In: Workshop on graphical modeling language development, Lyngby, DenmarkGoogle Scholar
- 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
- 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
- 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
- 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
- Forster F (2006) The idea behind business process improvement: toward a business process improvement pattern framework. BPTrends 2006:1–13Google Scholar
- Frank U (2010) Outline of a method for designing domain-specific modelling languages. ICB-Research Report, No. 42Google Scholar
- 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
- Frank U (2011b) The MEMO meta modelling language (MML) and language architecture. ICB-Research Report, No, p 43Google Scholar
- 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
- George ML, Rowlands D, Price M, Maxey J (2005) Lean six sigma pocket toolbox. McGraw-Hill, New YorkGoogle Scholar
- 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
- Gregor S, Hevner AR (2013) Positioning and presenting design science research for maximum impact. MIS Q 37(2):337–356Google Scholar
- 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
- 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
- Harel D, Rumpe B (2000) Modeling languages: syntax, semantics and all that stuff, Part I: the basic stuff. Technical Report MCS00-16Google Scholar
- Harel D, Rumpe B (2004) Meaningful modeling: what's the semantics of "semantics"? IEEE Computer 37(10):64–72Google Scholar
- Harmon P (2016) The state of business process management – 2016. a BPTrends report. http://www.bptrends.com/bpt/wp-content/uploads/2015-BPT-Survey-Report.pdf. Accessed 17 May 2017
- Harrington HJ (1991) Business process improvement - the breakthrough strategy for total quality, productivity and competitiveness. McGraw-Hill, New YorkGoogle Scholar
- Harrington HJ, Lomax KC (2000) Performance improvement methods: fighting the war on waste. McGraw-Hill, New YorkGoogle Scholar
- Hevner AR, March ST, Park J, Ram S (2004) Design science in information systems research. MIS Q 28(1):75–105Google Scholar
- 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
- 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
- Ishikawa K (1980) Guide to quality control. Asian Productivity Organization, TokyoGoogle Scholar
- 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
- 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
- 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
- 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
- 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
- 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
- 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
- Karagiannis D, Grossmann W, Höfferer P (2008) Open model initiative: a FEASIBILITY study. University of Vienna, Department of Knowledge Engineering, ViennaGoogle Scholar
- 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
- 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
- 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
- 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
- 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
- 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
- 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
- Lovelock C, Wirtz J (2011) Services marketing - people, technology, strategy, 7th edn. Pearson, SingaporeGoogle Scholar
- 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
- Magnusson K, Kroslid D, Bergman B (2004) Six Sigma umsetzen, 2nd edn. Hanser, MünchenGoogle Scholar
- 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
- McAfee A, Brynjolfsson E (2012) Big data: the management revolution. Harv Bus Rev 90(10):60–66Google Scholar
- McDonald MP, Aron D (2011) Executive summary: reimagining IT: the 2011 CIO agenda. Gartner ResearchGoogle Scholar
- McNeill K (2008) Metamodeling with EMF: Generating concrete, reusable Java snippets. http://www.ibm.com/developerworks/library/os-eclipse-emfmetamodel/index.html?S_TACT=105AGX44&S_CMP=EDU. Accessed 26 Jan 2016
- 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
- Object Management Group OMG (2015): OMG Unified Modeling Language TM (OMG UML) – version 2.5. http://www.omg.org/spec/UML/2.5. Accessed 25 May 2016
- Okes D (2002) Organize your quality tool belt. Qual Progress (July 2002), pp.82–86Google Scholar
- 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
- Poernomo I (2006) The meta-object facility typed. In: Proceedings of the 2006 ACM symposium on Applied computing. ACM, pp 1845–1849Google Scholar
- Povey B (1998) The development of a best practice business process improvement methodology. Benchmarking 5(1):27–44Google Scholar
- Rafferty AE, Jimmieson NL, Armenakis AA (2013) Change readiness. A Multilevel Review. J Manag 39(1):110–135Google Scholar
- Rigby D, Bilodeau B (2015) Management tools & trends 2015. Bain & Company, BostonGoogle Scholar
- Sauro J, Lewis JR (2012) Quantifying the user experience: practical statistics for user research. Elsevier, AmsterdamGoogle Scholar
- 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
- Snee R, Hoerl R (2003) Leading Six Sigma. Prentice Hall, New YorkGoogle Scholar
- 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
- Strahringer S (1996) Metamodellierung als Instrument des Methodenvergleichs. Shaker, AachenGoogle Scholar
- Thalheim B (2010) Towards a theory of conceptual modelling. J Univers Comput Sci 16(20):3102–3137Google Scholar
- 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
- 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
- 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
- van Veenendaal E (1998) Questionnaire based usability testing. In: Proceedings European Software Quality Week Conference, BrusselsGoogle Scholar
- Womack JP, Jones DT (1996) Lean thinking. Simon & Schuster, New YorkGoogle Scholar
- Womack J, Jones D, Roos D (2007) The machine that changed the world, 2nd edn. Free Press, New YorkGoogle Scholar
- 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
- Nayatani Y (1986) Seven management tools for QC. Rep Stat Appl Res JUSE 33(2):1–6Google Scholar