Towards a goal and problem based business process improvement framework – an experience report Björn Skoglund, Erik Perjons Department of Computer and Systems Science, Stockholm University, Stockholm, Sweden bjorns.skoglund@gmail.com, perjons@dsv.su.se Abstract. The interest in business process improvement (BPI) is vast among re- searchers and practitioners. However, it is difficult for an organisation to under- stand which BPI methods to introduce given a situation at hand. This paper de- scribes experiences from a major Swedish insurance company that carried out a BPI project but needed to know if further improvement could be achieved. In order to address this issue, a BPI framework was designed and applied on already improved business process diagrams. The BPI framework consists of various BPI tasks from different BPI methods, more precisely Six Sigma and Lean, and from research on so called duplicate systems. The framework also consists of goal and problem statements related to BPI tasks. These goals and problem statements aim to support the selection, combination, and application of the BPI tasks given a situation at hand. The application of the BPI framework showed that several fur- ther improvements of already improved business processes diagrams could be achieved. An evaluation of the BPI framework based on interviews with aca- demic experts and practitioners also showed promising results. Keywords: business process improvement, insurance process, Lean, Six Sigma, duplicate systems, goal model, problem model 1 Introduction Business process improvement (BPI) is an approach supporting organisation to make changes and optimize their way of doing business [1]. The interest for BPI has led to development and use of different BPI methods, for example Lean, TQM, Six Sigma. Most of these methods have been developed based on best practices from industries. A practitioner that aims to improve an organisations’ processes based on best prac- tices in a structured way needs to choose among all these improvement methods, and maybe combine different parts from different methods in order to develop a method that is appropriate for a certain organisation in a certain situation. This require a deep understanding on each of these BPI methods and included BPI tasks within the meth- ods, and how tasks from different methods can be chosen and combined. The problem that the paper addresses is that it is difficult for an organisation to find a BPI method that best suites the organisation at hand, either by selecting an existing BPI method or BPI tasks from different BPI methods. Copyright © 2020 for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0). This paper has its base in the experience from a large insurance company in Sweden. The company had carried out a BPI project, but did not followed any existing BPI method. The management of the company needed to know if further improvement could be achieved by using existing BPI methods. In order to address this issue, a BPI framework was designed by the authors of this paper. The framework was then applied on already improved business process diagrams, which were the result from the previ- ously carried out BPI project. The paper presents the BPI framework designed by the authors of this paper, the experiences from the application of the BPI framework on the already improved busi- ness process diagram of an insurance process in order to identify further possibilities of improvements. The paper also presents an evaluation in which academic experts and practitioners were evaluating the BPI framework. A set of requirements on the BPI framework have guided the research. The require- ments are the following: • Understandability: The BPI framework should be easy to comprehend for the user, which are mainly business managers, business analysts, business process designers, IT managers and requirement engineers at the insurance company as well as at other companies that plan to use the BPI framework. This means that the BPI framework should not be too complex. • Reflection and sense making: The framework should support reflection and sense making of carrying out BPI. This is an important requirements for or- ganisations that need to constantly improve their behavior, such as the insur- ance company and other companies acting in a competitive environment. • Efficient: The framework should make it possible to carry out BPI tasks in a time and resource efficient way. This is an important requirement for all cost aware companies. • Generic: The framework should be applicable on all types of organisations. That is, the framework should contribute to the generic practice, and not only to a local practice. To be generic is an important requirements within design science research on the artefacts designed, such as the BPI framework. De- sign science is the research approach used in the research that is presented in this paper. The structure of the paper is as follows: In Section 2, related research, and in Section 3, the research methodology are presented. In Section 4 the BPI framework is described, followed by a demonstration of the application of the framework in Section 5 and the expert evaluation in section 6. The conclusion is presented in Section 6. 2 Related research Many papers in the area of BPI presents information about BPI at a general level. Many of these papers also present a number of general steps that need to be conducted when carrying out BPI [e.g. 1,2,3]. These steps are in general the following, with some vari- ation: 2  Specify a business vision and the business process objectives. The business objectives include concepts such as cost reduction, time reduction, quality improvement, etc.  Identify the business processes to be improved, often focusing on the busi- ness processes that are most important for the organisation or the ones that are in conflict with the organisations’ business vision.  Identify how the business processes at hand could be measured, so that they can be improved.  Identify IT capabilities that could influence the design of the processes.  Design and prototype new or changed business processes. Other papers also include more detailed descriptions of the tasks to be carried out in BPI initiatives, many of them presenting BPI methods such as Lean, TQM and Six Sigma which all provide specific tasks to carry out [4,5,6,7,8]. There are also some papers presenting methods combining tasks from different BPI methods. For example, [9] created a method by selecting and combining the best tasks of the other already existing methods. He first identified weaknesses in existing BPI methods and then, based on that, created a BPI method that incorporate the key points of change management into the model, included benchmarking. Examples of weak- nesses in existing methods, according to [9], are that many BPI methods overlook that processes are “human activity systems”, that is, processes are carried out by people; and that BPI methods do not utilize the power of benchmarking. Another example of a method that are based on other already existing BPI methods is presented by [10]. They have created a “super methodology” by combining three key topics within business process improvement (BPI), i.e. continuous process improve- ment (CPI), business process reengineering (BPR), and business process benchmarking (BPB). The authors claim that different organisations have different needs for their BPI initiative. For example, one organisation may need an incremental improvement of business processes that are critical for the organisation, whereas another organisation need a total revamp of its business processes. Therefore, the BPI method needs to adapt to the situation at hand. The BPI framework presented in this paper support such a mindset. More precisely, the BPI framework presented in this paper supports design of a customized BPI method using BPI tasks from different existing BPI methods. An interesting approach also similar to the one presented in this paper is described by [11]. The authors investigated 29 different best practices for implementing business process redesign. The best practices were focusing on themes such as customers, busi- ness process orientation, business process behavior, organisation, information, technol- ogy, and external environment. A framework was given in the paper for classifying the best practices in order for practitioners to choose the best practice when working with implementing business process redesign. The quality of each best practice has been evaluated using criteria such as cost, quality, flexibility and time. In this paper, the BPI methods used are Lean and Sigma, as well as research on duplicate systems paradox. The duplicated system paradox is a situation “in which an organisation continuously allows multiple, overlapping, partially competing and largely incompatible information systems to persist and continue to evolve over time, despite continued awareness of the adverse consequences on organisational information management capabilities” [12]. 3 Research Methodology The research approach used in this project was design science. For presenting the result of our research, we follow a method framework for design science research presented in [13]. The framework specify of a number of logically related activities, with well- defined input and output. Moreover, the framework presents what research strategies and research methods and existing knowledge base are used in each activities. Accord- ing to [13] different research strategies and methods can be applied in each of the design science activities. In the research presented in this paper, a case study carried out at in a major insurance company in Sweden is the research strategy applied in several of the design science activities. As part of the case study, research methods such as interview and documents were used. The activities in design science and how they have been carried out in our research are presented below: 1. Explicate problem. The explicate problem activity is about justifying the problem to be addressed by showing that it is significant for some practice, and precisely formu- lating it. The problem statement for our research was that it is difficult for an organisa- tion to find a BPI method that best suites the organisation at hand, either by selecting an existing BPI method or select BPI tasks from different methods. The problem state- ment was formulated based on the need expressed by the management of the insurance company: The company had carried out a business improvement project, but it did not use any existing BPI method. The management team of the company needed to know if further improvement could be achieved using existing BPI methods. 2. Outline artefact and define requirements. The outline artefact and define require- ments activity transform the problem into demands on a proposed artefact. As with the problem statement, the requirements, were formulated based on the need expressed by the management of the insurance company. The requirements specified on the artefact, the BPI framework, are presented in Section 1, that is, the BPI framework should be understandable, efficient, support reflection and sense making and be generic. 3. Design and develop artefact. The design and develop artefact activity creates an ar- tefact that addresses the explicated problem and fulfils the defined requirements. The artefact created in our research was based on a literature study about BPI methods as well as the to-be business process diagrams resulted from a previous BPI project carried out at the insurance company (before our research started). The BPI framework was created during a number of conceptual modelling sessions between the authors of this paper. 4. Demonstrate artefact. The demonstrate artefact activity uses the developed artefact in an illustrative or real-life case, thereby proving the feasibility of the artefact. In our 4 research the demonstration is based on the case study carried out at the insurance com- pany. The artefact applied is the BPI framework. 5. Evaluate artefact. The evaluate artefact activity determines how well the artefact can solve practical problem that motivated the research as well as fulfils the stated require- ments. In our research, the BPI framework was evaluated by using interviews with ac- ademic experts and practitioners, more precisely, two academic experts and two prac- titioner. The BPI framework was presented and the academic experts and practitioners were interviewed regarding the problem to be addressed and the requirements to be fulfilled. 4 The BPI framework In this section the BPI framework is described. The BPI framework consists of six com- ponents.  A goal model  A problem model  BPI methods  BPI tasks  The relationship model  The action unit pattern 4.1 The goal model The goal model is a set of goal statements with top goals and their sub-goals, see Figure 1 in which one of the top goal and its sub-processes are described. The goals and sub- goals are related, explicitly in the Relationship model (see below), to BPI methods and BPI tasks in order to explicitly state which goals BPI methods and BPI tasks aims to achieve. The relationships between the goals and sub-goals are a “part of” relationship. The goals in the goal models have been identified by elaborating possible goals that each given BPI task and BPI method can achieve, in a sort of “reverse engineering” approach. The efficiency shall be high Productivity in a process The cost per unit in a process The flow of activity/operations in shall be raised shall be lowered. the process shall be continuous Fig. 1. A goal statement with a top goal and its sub-goals 4.2 The problem model The problem model is a set of problem statements with problems and their sub-prob- lems, see Figure 2, that are related, explicitly in the Relationship model (see below), to BPI methods and BPI tasks in order to explicitly state which problem the BPI methods and BPI tasks can address. The relationships between the problems and sub-problem are a “part of” relationship. The problem in the problem model have been identified by elaborating possible problem that each given BPI task and BPI method address, again in a sort of “reverse engineering” approach. The efficiency is low The productivity is low, i.e. amount of The cost per unit is high, The process flow is not a continuous resources used when carrying out the i.e. the cost of producing a one, i.e. the process consists of process is high good or a service is high waiting time. Fig. 1. A problem statement with a problem and its sub-problem 4.3 The BPI methods The BPI methods are a set of existing and new methods consisting of a BPI tasks. In our framework, the BPI methods are Lean, Six Sigma and the duplicate systems. The two first BPI method were chosen because they are two leading BPI methods that pro- vide a number of concrete BPI task to be used. The third method is not a well-known BPI method but provide a base for identify BPI improvement tasks related to the IT system support of business processes. 4.4 The BPI tasks The BPI tasks are a set of tasks that can be carried out in order to improve business processes. In our framework, the BPI tasks are tasks within the Lean and Six Sigma methods and tasks designed based on the ideas from the duplicate system. Example of tasks are Value Stream Mapping (VSM), Fishbone analysis, Continuous flow, Kaizen, 5S, Identifying duplicate systems, Eliminating double documentation in IT systems. Each task is described following a pattern: name of the task, problem that the task ad- dress, benefit of the task, risk of using the task. 4.5 The Relationship model The relationship model is a model describing a set of specified relationships between the previous four components, which makes the relationships between the previous four components explicit, see Figure 3. Thereby, a user of the framework can navigate be- 6 tween the components. For example, given problems and their sub-problems in an or- ganisation, a user of the relationship model can identify which BPI task to apply as well as to which BPI methods these tasks are part of, see Figure 4. To identify problems that is an opposite/inverse state in relation to the goal state Goal model To identify the goals that is achieved Problem model when a problem is addressed To identify To identify BPI To identify To identify BPI the goals tasks that problems that methods that for the BPI fulfill goals a BPI method solves certain task solves problems To describe BPI tasks in detail for a BPI tasks certain BPI method BPI methods To identify BPI methods for witch a certain task is included in Fig. 3. The relationships between goal model, problem model, BPI tasks and BPI methods. General problems The information and material The process is not The efficiency is low flow is not efficient continuously improved Information- Sub problems The The cost The process and material The business is productivity is per unit is flow is not a flows are not returning to old Processes are not low, i.e. high, i.e. continuous coordinated habits after the continuously amount of the cost of one, i.e. the in an efficient process The business is improved, i.e. the resources producing process way improvement not changing in process are not used when a goods or consists of project the same pace as improved during carrying out a service is waiting time the business the life times task or the high environment process Value Stream Kaizen BPI tasks Continuous flow Mapping (VSM) BPI methods Lean Fig. 4. Given a problems and their sub-problems in an organisation, the user can identify which BPI tasks to apply as well as to which BPI methods these tasks are part of. 4.6 The Action pattern The action pattern is a pattern to be used when analyzing each action in the business processes in detail. The pattern consist of the following parts: name of action, D description of action, purpose of action, input to action, output of action, IT involved, roles involved, other tools involved, control involved. The relationship between the parts of the action pattern are visualized using a IDEF0 diagrams, see Figure 5, showing how input is transformed to output, supported by IT system, other tools and roles, and governed by control. Control (such as routines, rules to follow) Name of action Description of action Input Purpose of action Output (from (transformed previous IT system Other input) Roles activity) tools Fig. 5. The parts of the action unit pattern represented as an IDEF0 diagram. 5 Demonstration The BPI framework has been applied on an insurance process at one of the major in- surance companies in Sweden. The company had carried out a BPI project where the insurance process, called regulate damage process, has been improved. The BPI project at the insurance company was carried out in the following way (and done before we did our research): First, the company visualized the way of working in the organisation in as-is process diagrams, Second, the way of working was analyzed and suggested improvements were identified in workshops with process participants. Third, based on results from workshops, to-be process diagrams were created. At the insurance company, the regulate damage process was divided into three sub-processes: Gather information of the parts, Make decision (about compensation) and Perform reg- ulation. Seven different IT system support the process/sub-processes, see Figure 6. The work in the BPI project did not follow any specific BPI method, and the man- agement team of the insurance company wanted to know if further improvement of the insurance process could be achieved by applying existing BPI methods on the to-be created process diagrams. In order to investigate this, the authors of this paper design and developed the BPI framework, presented in Chapter 4, and applied it in a number of steps: Step 1: The action pattern was applied on the existing to-be processes diagram. For each action, the following parts were specified: the name of the action, the description of the action, the purpose of the action, the input and output, control, as well as inter- action with IT, other tools, and roles were identified and documented. Result of step 1: Step 2 resulted in new detailed to-be process descriptions. This new detailed to-be process descriptions were validated by interviewing process participants and process owners at the insurance company. In total 125 actions were described in this detailed way. 8 Insurance Process/Regulate damage Gather information Input: Output: Occured Registered damage damage Make decision Input: Output: Registered Set compensation damage assessment Perform regulation Input: Output: Set compensation Regulated assessment damage Outlook Damage list USYS GSR Ett KUND LFAB SKAVI system System System with System with System System for System used System for supporting information information supporting storing for insurance handling investigations aobut about customers information cases work as reinsurance customer customers to notify a about a ”to-do-list” history in all and their damage via damages insurance agreements website companies and contacts Fig. 6. The regulate damage process and its sub-process, and IT system supporting the pro- cess/subprocesses. Step 2: The problem model, the goal model and BPI tasks were applied in order to identify possible problem and improvement possibilities. The reason for apply all three components in the same time on each action, was that sometimes a problem in problem model triggered the idea of how to improve an action, other times it was a BPI task or a goal that triggered such an improvement. Result of step 2: This step resulted in a set of actions with possible improvements. Step 3: The relationship model was applied in order to analyze in detail each action found in previous step were improvements was possible. This step resulted in a detailed analysis of each step where improvement was possible, including which BPI task to apply. Result of step 3: This step resulted in an analysis of the actions with possible im- provements, see Table 1. Table 1: Action with possible improvements Problem identified Example from process BPI task to apply Similar information are docu- Example 1: An insurance claim Eliminating double documenta- mented in several systems in the that is documented in damage tion in IT systems (by, for exam- same action ple, integrating the two systems system also needs to be docu- so that information or part of the mented in Outlook list. information documented in one Example 2: When an invoice is system is transferred automati- received from a partner, it needs cally to another system). to be documented in both the damage system and the Outlook list. Multiple systems make it unclear Example 1: If the case is re- Identifying duplicate systems in which system the information ported to the group managing (so that information can be doc- should be documented and/or is risks this is not informed in the umented in both systems or to be found damage system, only in the Ett make the routines clear so every- KUND. body knows in which system the Example 2: All damage claims information should be docu- should be shown in Ett KUND, mented and/or is to be found). this is not always the case. Collaboration in processes are When a claim is about a big dam- Introduce IT system supporting not supported by existing IT sys- age and/or several depart- collaborative work and decision tems. ments/units are involved in an making (so that several employ- insurance claim, the IT systems ees can collaborate around a case used for documentation do not in an effective and efficient support the collaboration in an way). effective way. Activities that could be carried Many of the actions in subpro- Apply continuous flow (so that out in parallel are carried out in cess 2: ”Make decision” could the insurance claim will be fin- sequence, which slow down the be carried out in parallel but are ished earlier, which will give the flow of the case. carried out in sequence. customer an earlier end result). Customer is contacted at several A customer can be contacted at Apply continuous flow (so that occasions, which slow down the several occasions in the insur- the insurance claim will be fin- flow of the case. ance claim process, for example ished earlier, which will give the when the customer is asked for customer an earlier end result). the cause of the damage, during inspection, and during investiga- tion as well as to add further in- formation during the process. Unnecessary activities are car- If a contractor has categorized an Apply continuous flow (so that ried out. insurance claim for the wrong the insurance claim will be fin- unit/department, the case is sent ished earlier, which will give the back by the assessor to the con- customer an earlier end result). tractor for re-categorization in- stead of the assessor himself/her- self re-categorize the case. 10 Step 4: Finally, the BPI method was applied in order to see if some BPI method could be used in full instead of combining BPI tasks from different BPI methods. Result of step 4: Most of the actions to improve were using tasks from Lean (contin- uous flow) and duplicate system. 6 Evaluation In this section, the result of the evaluation of the BPI framework is presented. The eval- uation was carried out using interviews with two academic experts and two practition- ers. The first academic experts is a senior lecturer with expertise in business process modelling and service science. The other academic expert is a PhD student but has worked as a teacher for many years in university courses in business process modelling. Both practitioners work at the insurance company that has been part of the case study, the first one was BPI expert at the insurance company and the second one is a business development manager at the insurance process. The evaluation was carried out in the following way: First, the BPI framework and the resulting application on the insurance process was presented for each of the interview- ees. The four interviewees were interviewed at different occasions. Second, the inter- view sessions were carried out in a semi-structured way asking questions about the overall impression of the BPI framework, the benefit and drawback of the framework, possible improvements and how the specified requirements were fulfilled. On average, each interview took 1 ½ hour. The interviews were recorded and transcribed. Third, a thematic data analysis was performed based on the specified requirements. 6.1 Summary of the evaluation In this section the overall summary of each interviewee is presented, including benefits, drawbacks and suggested improvements. Interviewee 1 (BPI expert at the insurance company) explained that the BPI framework is very clear and easy to follow, and the interviewee states that a supreme quality of the BPI framework is the fact that a practitioner can start from anywhere (from any com- ponent) in the framework. The interviewee also stated that some basic knowledge about BPI tasks, BPI methods goal and problem models are needed to use the framework: a general business developer may not have that knowledge and may therefore not use the framework in full. The efficiency of the BPI framework may be harmed in that way. Interviewee 1 also stated that theoretical models often tend to simplify the real world and that this could also be the case in this framework. Interviewee 2 (senior lecturer with expertise in business process modelling and ser- vice science) claimed that the framework is very useful for any organisation, and it seems to be easy to use for a practitioner. The strength of the framework is the goal and problem models, which are mapped to existing BPI methods and BPI tasks which makes it much easier to really browse the existing methods and select one that is ap- propriate for a certain problem. However, interviewee 2 mentioned that there is a lack of guidance on how one should approach this framework given a problem in an organ- isation. Interviewee 2 also stated that the goal and problem model will easily be clut- tered using a hierarchy of sub-goals and sub-problem, and therefore these models might needs an easier structure so that practitioners can follow them. Interviewee 3 (PhD student and teacher in business process modelling) emphasize the benefit of the connections between components which clarify how the different parts are connected. Interviewee 3 noticed that different methods have different names on the BPI tasks but that they perform pretty much the same thing. This need to be addressed by the framework and suggest stricter use of patterns describing the BPI tasks. The BPI tasks could also be further categorized in which way they handle prob- lems, control flow, time, etc. Interviewee 4 (business development manager at the insurance company) claimed that the strength of the framework is that it is supporting different approaches for BPI initiatives. For example, when defining goals in a BPI projects one wants to know what BPI methods and BPI tasks to use to achieve those goals. In the same way, if a one want to address certain problems, one can find the different BPI methods and BPI tasks that can be used for that. Interviewee 4 stated that the framework need some IT support to manage all possible goals, problems, BPI methods, and BPI tasks in an efficient way. 6.2 Fulfillment of stated requirements In section 1, four requirements on the artefact/framework were presented and moti- vated. These four requirements were a major focus in the evaluation, and the results from the evaluation of the requirement fulfillment are presented below: Requirement 1: Understandability. The framework should be easy to comprehend for the user, which are mainly business managers, business analysts, business process de- signers, IT managers and requirement engineers. Evaluation result of requirement 1: Interviewee 1 stated that if someone is updated theoretically, the framework is easy to understand, but if someone does not have basic knowledge about BPI methods, BPI tasks, or goal and problem models this framework could be hard to understand and, thereby, to use. Interviewee 2 claimed that the general idea of the framework is easy to understand for users. Interviewee 3 thought that users will not have any bigger problems understanding and using this framework. Interviewee 4 claimed that the framework is easy to understand for all types of practitioners. Requirement 2: Reflection and sense making: The framework should support reflection and sense making of carrying out BPI. Evaluation result for requirement 2: Interviewee 1 claimed that if it is used in a correct way then it would support reflection and sense making. Interviewee 2 thought that the framework fulfills this requirement because the framework does give the users an opportunity to really look at several different BPI methods and to collect the best 12 BPI tasks from them all. Interviewee 3 argued that it is rather tools than frameworks that support reflection and sense making when carrying out BPI. Interviewee 4 could not answer this question. Requirement 3: Efficient: The framework should make it possible to carry out BPI tasks in a time and resource efficient way. Evaluation result for requirement 3: Interviewee 1 claimed that understanding the BPI tasks still may take some time. Interviewee 2 claimed that the support to select different BPI tasks from different BPI methods makes the framework very efficient. Interviewee 3 stated that the framework is efficient using the components to find the BPI tasks and that the framework also can work as a communication tool between us- ers. Interviewee 4 claimed that the framework is efficient since it support the finding of alternative BPI tasks and BPI methods, given problems and goals. Requirement 4: Generic: The framework should be applicable on all types of organisa- tions. That is, the framework should contribute to the generic practice, and not only to a local practice. Evaluation result for requirement 4: All interviewees claimed that the BPI frame- work is generic and can be applied on all type of organisations. 7 Conclusion In this paper, experiences from a major Swedish insurance company carrying out BPI are presented. The company had carried out a BPI project but did not use any specific BPI method. Therefore, the management team wanted to know if further improvement could be identified based on the created to-be process diagrams from the previous BPI project, and by applying existing BPI methods. To address this issue a BPI framework was designed and developed based on existing BPI methods, more precisely, Lean, Six Sigma, and research on duplicate system. The BPI framework was applied on the ex- isting to-be process diagrams and further improvements could be identified. The BPI framework was also evaluated by interviewing academic experts and practitioners. The result of the evaluation showed that several of the interviewee thought that the BPI framework was easy to understand, efficient to use and generic. Some of the interview- ees also thought that the BPI framework supported reflection and sense making. Note, however, that no generalized conclusion could be stated since only four persons were interviewed. One interviewee claimed that the use of the BPI framework requires some basic knowledge of BPI methods as well as goal and problem models. Another inter- viewee claimed that some of BPI tasks were similar to each other, and this should be addressed in the next version of the BPI framework. A third interviewee expressed the need for an IT tool supporting the use of the BPI framework. We are planning to continue the research by extending the framework with addi- tional components important for succeeding with BPI, such as benchmarking/key per- formance indicators, change management/engagement techniques, individual and or- ganisational learning techniques, and case studies. The case studies make it possible to identify documented experiences from using, for example, a certain BPI task. This will increase the use of best practices. We are also planning to include further BPI methods and BPI tasks, and especially make it clear how similar BPI tasks are different, by using more detailed pattern describing the BPI tasks. A tool supporting the use of the BPI framework is an important task as well, as one of the interviewee’s in the evaluation stated. Important for improving the BPI framework is to continue applying it in real life organisations. References [1] Zellner, G. (2011). A structured evaluation of business process improvement approaches. Business Process Management Journal, 17(2), 203-237. [2] Holtzman, Y. (2011). Business process improvement and the tax department. Journal of Management Development, 30(1), 49-60. [3] Adesola, S., & Baines, T. (2005). Developing and evaluating a methodology for business process improvement. Business Process Management Journal, 11(1), 37-46. [4] Harmon, P. (2010). Business process change: A guide for business managers and BPM and Six Sigma professionals. Morgan Kaufmann. [5] Walley, P., Stephens, A., & Bucci, G. (2006). Evaluation of the lean approach to business management and its use in the public sector. Edinburgh: Scottish executive social research. [6] Modig, N., & Åhlström, P. (2012). This is lean: Resolving the efficiency paradox. Rheologica. [7] Womack, J. P. and Jones, D. T. (1996) Lean Thinking, New York, Simon & Schuster. [8] Dedhia, N. S. (2005.) Six Sigma Basics, Total Quality Management, Vol. 16, No. 5, pp 567–574. [9] Povey, B. (1998). The development of a best practice business process improvement methodology. Benchmarking for Quality Management & Technology, 5(1), 27-44. [10] Lee, K. T., & Chuah, K. B. (2001). A SUPER methodology for business process improvement-An industrial case study in Hong Kong/China. International Journal of Operations & Production Management, 21(5/6), 687-706. [11] Reijers, H. A., & Mansar, S. L. (2005). Best practices in business process redesign: an overview and qualitative evaluation of successful redesign heuristics. Omega, 33(4), 283- 306. [12] Wimelius. H. (2011). Duplicate systems: investigating unintended consequences of information technology in organizations, Doctoral dissertation, Umeå University. [13] Johannesson, P., & Perjons, E. (2014). An Introduction to Design Science. Springer. 14