=Paper=
{{Paper
|id=Vol-2586/paper6
|storemode=property
|title=Towards a Goal and Problem based Business Process
Improvement Framework – an Experience Report
|pdfUrl=https://ceur-ws.org/Vol-2586/paper6.pdf
|volume=Vol-2586
|authors=Björn Skoglund,Erik Perjons
|dblpUrl=https://dblp.org/rec/conf/ifip8-1/SkoglundP19
}}
==Towards a Goal and Problem based Business Process
Improvement Framework – an Experience Report==
https://ceur-ws.org/Vol-2586/paper6.pdf
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