MODEL-BASED FAILURE ANALYSIS OF BUSINESS PROCESS
Xiaocheng Ge, Richard F. Paige and John A. McDermid
Department of Computer Science, University of York, York, U.K.
Keywords:
Business process, Failure analysis, Health information system.
Abstract:
The success of most organisations are based on how well the organisation can engineer and execute their
business processes in order to better manage the extra value that these processes can provide. However,
business processes may fail to deliver the functions which are designed. In order to help the understanding
of how and why a business process may fail, we considered the techniques in system safety engineering
and integrated them with existing techniques of business process modelling and analysis. We proposed a
framework of business process failure analysis. The kernel of the framework is that we extended the workflow
net of a business process by modelling failures as coloured tokens and so that the failure behaviours of the
business process can be simulated. In addition, we developed a tool based on the codes of an open source
project to support the analysis. The applications of proposed technique have demonstrated that it is a powerful
and easy-to-use technique for the management of business processes in large complex enterprise systems.
1 INTRODUCTION
The concept of business process has received consid-
erable attention by the community of business admin-
istration as organisations have been seeking how they
do their business more efficiently.
And some organisations are process-centric, i.e,
the business of such organisations are usually divided
and managed according to their business processes.
The examples of such process-centric organisations
are banks and hospitals. Any failure in their business
processes will directly lead to a disaster to their busi-
ness. For example, considering a hospital discharge
system, a failure in the execution of the hospital dis-
charge process may cause troubles to both the patient
who is discharged from the hospital and the hospital
itself because the failure may lead to serious impacts
e.g, a delayed discharge, or re-hospitalisation, or even
death of patients. Thus, when (re)engineering a busi-
ness process, the managers and engineers who are in-
volved always have to answer following questions:
Why can this process fail?
How can this process fail?
And in most cases, the failure of a business process is
due to the failures of the activities in the process. So
the additional questions can be asked:
How is a process effected by a failure of an indi-
vidual activity in the process?
What is the most vulnerable activity in the pro-
cess?
How can potential failures be eliminated or con-
trolled?
These questions cannot be answered without hav-
ing a clear understanding of the business process and
its environment.
In system engineering, a few techniques, e.g, Fail-
ure Mode and Effect Analysis (FMEA), have been
proposed and successful applied to analyse hazards
and failures in safety-critical systems. In this pa-
per, we propose a framework which integrates the
concepts and practices of FMEA especially process
FMEA from safety engineering domain with existing
technique of process modelling and analysis from the
domain of BPM so that the failure analysis and per-
formance analysis of a business process is bridged to-
gether.
The core of our framework is a model of faults
propagation in the business process, which is a Petri
net model with extension of colour, called Failure net.
388
Ge X., F. Paige R. and A. McDermid J..
MODEL-BASED FAILURE ANALYSIS OF BUSINESS PROCESS.
DOI: 10.5220/0003496203880391
In Proceedings of the 13th International Conference on Enterprise Information Systems (ICEIS-2011), pages 388-391
ISBN: 978-989-8425-55-3
Copyright
c
2011 SCITEPRESS (Science and Technology Publications, Lda.)
2 FRAMEWORK OF BUSINESS
PROCESS FAILURE ANALYSIS
2.1 Definition of Business Process
A business process, by its definition in (OMG, 2008),
is a collection of related, structured activities. The
specification of a process defines the set of activities
as well as the procedure and conditions on when such
activities will be performed, i.e, in what order an ac-
tivity is executed and how. To emphasise that a busi-
ness process may have a hierarchical structure, here
we add a sentence to this definition that a business
process is composed of a set of activities linked to-
gether in order to interact, where each activity is an-
other process, etc; The recursion stops when an ac-
tivity is considered to be atomic: any further internal
structure cannot be discerned, or is not of interest and
can be ignored.
Failure is the term in our research to describe a
state or condition which does not meet a desirable
or intended objective, and is viewed as the opposite
of correctness. For the analysis of business process
failure, it is also necessary to distinguish two terms:
function and service. In our research, the term func-
tion is used to refer to what the process is intended
to do and is usually detailed in the specifications in
terms of functionality and performance; and the term
service is used to describe what the instance actually
behaves to achieve the function of the process.
2.2 Framework of Business Process
Failure Analysis
Business Process Failure Analysis (BPFA) has a sim-
ple process, which is shown in Figure 1. During the
analysis process, the business process being reviewed
is firstly step. The entire business process is modelled
into smaller activities (t1 in Figure 1). Next, the pro-
cess managers can register all possible failure modes
to the system so that the process designers/engineers
can model the propagation behaviour of each activity
according to the failure modes. Then for each activity,
the faults, and possible causes of each faults are iden-
tified and documented (t3.1 in Figure 1). After all ac-
tivities are analysed, the business process is reviewed
by applying selected faults in the process model and
simulating their propagation process through the busi-
ness process (t4 in Figure 1).
In the process of BPFA, the activity t1 is impor-
tant, but we will not explain it in details because it
has been discussed as the same as in papers of mod-
elling business process in workflow net. In this paper,
our focus is the rest activities of BPFA which are real
contributions of our research.
2.2.1 Modelling Failure as Coloured Tokens
Once all activities are identified, for each activity, the
following steps are performed:
1. Define the activity being analysed.
2. Define the functions of the activity being anal-
ysed.
3. Identify all potential failures for the activity.
4. Determine the possible causes of each potential
failure.
During the execution of a business process, a cor-
rect service is delivered when the service satisfies the
specification of the process function. A service fail-
ure, often abbreviated here to failure, is an event that
occurs when the delivered service deviates from cor-
rect service.
We can describe the failure of a process from the
following dimensions/categories:
completeness, whether the outcome of the pro-
cess is complete?
validity, whether the outcome of the process last
for a right period of time?
consistency, whether the outcome of the process
is consistent whenever the process is executed?
timeliness, whether the outcome of the process is
generated on time?
accuracy, whether the outcome of the process is
adequate for the purpose?
To identify the possible failures of an activities
and then analyse them in a systematic approach, we
designed a set of tables to help the analysis and the
documentation. Table 1 is an example. The table is
activity-based, i.e, there is a table for each activity.
For each activity we need to list all possible failures
in each failure dimensions/category listed above, and
the references which cross-links the failure to the re-
quirements or standards of the activity. In the table we
also have to identify the possible causes of each fail-
ures which can help us to trace back the root of each
failure. Table 1 lists a part of this failure analysis of an
activity (Blood Test) in the process of stroke care in
hospital ER department. For the category complete-
ness, the activity may have a failure of incomplete-
ness, i.e, less results of blood test provided. This fail-
ure is directly against the requirements of the national
clinic guide.
In the analysis, we cared about not only all pos-
sible failures at each activity, but also the causes of
MODEL-BASED FAILURE ANALYSIS OF BUSINESS PROCESS
389
Figure 1: BPFA process.
those failures. The operation of an activity in the busi-
ness process is designed to transform inputs into use-
ful outputs. However, the failure may occur during
the operation of the activity. The causes can be either
the incorrect result of previous activity in the process,
or some internal errors during the operation of this ac-
tivity. By modelling the business process with failures
as a coloured workflow net, we can easily define each
activity may have one of following failure behaviours:
propagation, the colour of output token is as same
as input token’s of an activity;
transformation, the colour of output token is dif-
ferent.
An example of failure behaviours can also be
found in Table 1. In its operation of this activity, new
failure can be introduced due to internal errors; or fail-
ure transformed from one to another (e.g., informa-
tion that is erroneous when it received at the activity
remains erroneous when it delivers to the next activ-
ity), or transforms to a failure of a different category
(in Table 1, an incorrectness failure is transformed to
an incompleteness failure by the activity Blood Test.).
Once the failure analysis of all activities has been
done, the rest work is to simulate the process model
and review the results of the simulation.
2.3 Failure Analysis of the Business
Process
In general, failure net is based on the workflow net
model of a business process with an extension of
coloured tokens. Coloured tokens models fault ser-
vices of activity, and the correct service of an activity
is mark with default colour(i.e, black).
Simply speaking, the purpose of failure analysis
of a business model is to answer the questions listed
at the beginning of this paper. Simulation of Petri nets
as mature technique and well-supported by most tool
can fit for this purpose. By review the results of the
simulation, the failure behaviours of a business pro-
cess can be explored in much details so that the eval-
uation or re-engineering work of the business process
can be done.
2.4 Tool Support
WoPeD (Workflow Petri Net Designer)
1
is an open-
source software. It provides a simple software tool for
modelling, simulating and analysing workflow pro-
cess and resource descriptions using workflow nets,
an extended class of Petri nets. Based on the codes of
WoPeD, we developed a tool to support our proposed
failure analysis of business process.
3 APPLICATIONS OF FAILURE
NET
In the project, we collaborated with our partners to
help the improvement of NHS stoke care service in
North Yorkshire. In this section, we will briefly
demonstrate how we applied our BPFA to evaluate the
process of stroke care service, and discuss our find-
ings of failure analysis of business process in general.
3.1 Failure Analysis of Stroke Care
Process
In the case study, there are 16 key activities in the
process
2
. For this particular failure (incorrect judge-
ment after activities of review investigation results,
we identified various reasons which may cause the
failure. And the most important is that we also iden-
tify the most vulnerable activities which may cause
the failure. They are A5 - judgement of application of
urgent thrombolysis with 3 hours, A9 - clinic presen-
tation, A10/11 - review history of health care and
1
http://www.woped.org/
2
it excludes the last activity - classify whether is acute
stroke or TIA, or haemorrhagic strok, or other attacks, be-
cause the analysis is performed to identify the key reasons
of causing the incorrect judgement of acute stoke or TIA
patients.
ICEIS 2011 - 13th International Conference on Enterprise Information Systems
390
Table 1: An example of activity failures.
ID: A16 Activity/Process: Blood tests
Index Category Possible Failure Reference Possible Cause
1 Completeness
Incomplete results: Activity
A16 should provide results of at
least 5 different types of blood
test, including blood glucose
level, full blood count (FBC),
urea, electrolytes and creatinine.
Ref 25: The diagnosis and
acute management of
stroke and transient
ischaemic attacks. NICE
2008
Some tests are not
requested by mis-
take.
A15.7: incorrect
judgement of Ac-
tivity A15: Inves-
tigations
Figure 2: An Example of Business Process Failure Analysis.
examinations, and A17 - brain imaging.
During the analysis, we found that the quality of
the services provided by those activities are highly
relied on the experience and skills of the operators.
Thus to improve the quality of entire stroke care ser-
vice in the area, the central/local government should
focus on those key activities and the efforts to improve
the service may include various training, the mecha-
nism of reviewing, etc.
4 CONCLUSIONS
We have presented a new approach for the failure
analysis of business process, based on its failure net
models. The proposed technique enables the assess-
ment of failure behaviour from the analysis of each
activity in the business process. The proposed tech-
nique fully takes the advantages of using Petri net to
model and analyse business processes, but also inte-
grates the techniques of failure analysis from system
engineering with existing techniques in business pro-
cess management. The approach is easy to use and
tool supported.
There are still a lot of work to do in the area of
evaluation of proposed technique and the develop-
ment of tool, for example, we considered to imple-
ment several plug-ins so that business process mod-
elled by other methods, such as UML and BPMN,
can be imported and analysed. We are also explor-
ing techniques to visually represent and automatically
generate analysis results.
REFERENCES
(OMG, 2008). Business process definition metamodel
(BPDM), Process Definitions.
MODEL-BASED FAILURE ANALYSIS OF BUSINESS PROCESS
391