The interest in business process improvement (BPI) is vast among researchers and practitioners. However, it is difficult for an organisation to understand which BPI methods to introduce given a situation at hand. This paper describes 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 further improvements of already improved business processes diagrams could be achieved. An evaluation of the BPI framework based on interviews with academic experts and practitioners also showed promising results.
Business process improvement (BPI) is an approach supporting organisation to make
changes and optimize their way of doing business [
A practitioner that aims to improve an organisations’ processes based on best practices 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 methods, 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 previously 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 business 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 requirements 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 organisations that need to constantly improve their behavior, such as the insurance 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. Design 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
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 variation:
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 business 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 [
There are also some papers presenting methods combining tasks from different BPI
methods. For example, [
Another example of a method that are based on other already existing BPI methods
is presented by [
An interesting approach also similar to the one presented in this paper is described
by [
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
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 welldefined input and output. Moreover, the framework presents what research strategies and research methods and existing knowledge base are used in each activities. According 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 formulating it. The problem statement for our research was 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 select BPI tasks from different methods. The problem statement 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 requirements 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 artefact 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 research the demonstration is based on the case study carried out at the insurance company. 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 requirements. In our research, the BPI framework was evaluated by using interviews with academic experts and practitioners, more precisely, two academic experts and two practitioner. 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
In this section the BPI framework is described. The BPI framework consists of six components.
A goal model A problem model BPI methods BPI tasks The relationship model
The action unit pattern 4.1
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 subgoals 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.
Productivity in a process shall be raised
The cost per unit in a process The flow of activity/operations in 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 is a set of problem statements with problems and their sub-problems, 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 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 provide 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 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 address, benefit of the task, risk of using the task. 4.5
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 between the components. For example, given problems and their sub-problems in an organisation, 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 when a problem is addressed
Problem model The The cost productivity is per unit is low, i.e. high, i.e. amount of the cost of resources producing used when a goods or carrying out a service is task or the high process
Continuous flow
The process flow is not a continuous one, i.e. the process consists of waiting time
Informationand material flows are not coordinated in an efficient way Value Stream Mapping (VSM)
Lean
BPI tasks to apply as well as to which BPI methods these tasks are part of. 4.6
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 To identify the goals for the BPI task
To identify BPI tasks that fulfill goals BPI tasks
To describe BPI tasks in detail for a certain BPI method To identify BPI methods for witch a certain task is included in 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
Purpose of action Input (from previous IT system Other Roles activity) tools
Output (transformed input) The BPI framework has been applied on an insurance process at one of the major insurance 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 regulation. 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 management 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 interaction 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. Outlook list System used for insurance cases work as a ”to-do-list”
Insurance Process/Regulate damage Input: Occured damage Input: Registered damage Input: Set compensation assessment USYS System supporting investigations
Gather information
Make decision Perform regulation
Ett KUND System with information about customers and their agreements and contacts
GSR System with information aobut customer history in all insurance companies
LFAB System for handling reinsurance
Output: Registered damage Output: Set compensation assessment Output: Regulated damage
SKAVI System supporting customers to notify a damage via website
Damage system System for storing information about damages Fig. 6. The regulate damage process and its sub-process, and IT system supporting the process/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 improvements, see Table 1. system also needs to be documented in Outlook list.
Example 2: When an invoice is received from a partner, it needs to be documented in both the damage system and the Outlook list.
Example 1: If the case is reported to the group managing risks this is not informed in the damage system, only in the Ett KUND.
Example 2: All damage claims should be shown in Ett KUND, this is not always the case.
When a claim is about a big damage and/or several departments/units are involved in an insurance claim, the IT systems used for documentation do not support the collaboration in an effective way.
Many of the actions in subprocess 2: ”Make decision” could be carried out in parallel but are carried out in sequence.
A customer can be contacted at several occasions in the insurance claim process, for example when the customer is asked for the cause of the damage, during inspection, and during investigation as well as to add further information during the process.
If a contractor has categorized an insurance claim for the wrong unit/department, the case is sent back by the assessor to the contractor for re-categorization instead of the assessor himself/herself re-categorize the case.
so that information or part of the information documented in one system is transferred automatically to another system).
Identifying duplicate systems (so that information can be documented in both systems or make the routines clear so everybody knows in which system the information should be documented and/or is to be found).
Introduce IT system supporting collaborative work and decision making (so that several employees can collaborate around a case in an effective and efficient way).
Apply continuous flow (so that the insurance claim will be finished earlier, which will give the customer an earlier end result).
Apply continuous flow (so that the insurance claim will be finished earlier, which will give the customer an earlier end result).
Apply continuous flow (so that the insurance claim will be finished earlier, which will give the customer an earlier end result).
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 (continuous flow) and duplicate system. 6
In this section, the result of the evaluation of the BPI framework is presented. The evaluation was carried out using interviews with two academic experts and two practitioners. 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 interviewees. The four interviewees were interviewed at different occasions. Second, the interview 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
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 component) 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 service 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 appropriate 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 organisation. Interviewee 2 also stated that the goal and problem model will easily be cluttered 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 problems, 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
In section 1, four requirements on the artefact/framework were presented and motivated. 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 designers, 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 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 users. 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 organisations. 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 framework is generic and can be applied on all type of organisations. 7
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 existing 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 interviewees 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 interviewee 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 additional components important for succeeding with BPI, such as benchmarking/key performance indicators, change management/engagement techniques, individual and organisational 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.