Download - Quality-aware Business Process Management
Quality-aware Business Process Management
by
Mitra Heravizadeh, BInfoTech Hons.
Thesis
Submitted to the Faculty of Science and Technology for fulfilment of the Requirements for the Degree of
Doctor of Philosophy
at Queensland University of Technology
November 2009
To memory of my father Mehdi Heravizadeh and my motherAshraf Mahdavi, who always believed in me
VI
VII
Supervisory Panel
Principal Supervisor
Professor Michael Rosemann
Business Process Management Group
Information Systems Program
Faculty of Science and Technology
Queensland University of Technology
Associated Supervisor
Dr Wasana Bandara
Business Process Management Group
Information Systems Program
Faculty of Science and Technology
Queensland University of Technology
Associated Supervisor
Professor Jan Mendling
Institut fur Wirtschaftsinformatik
Wirtschaftswissenschaftliche Fakultat
Humboldt-Universitat zu Berlin
VIII
IX
Acknowledgement
This work would have not been possible without the support of my loved
ones. I would like to thank my lovely daughter who has put up with me
for not being there all the time. Thank you Sanaz for your love, support
and understanding. Thank you for reminding me daily about what is truly
important in life.
My sincere thanks to my supervisory team; Professor Michael Rosemann,
Dr Wasana Bandara, and Professor Jan Mendling. Thank you Michael for
your confidence in me and accepting to be my principle supervisor late
through my Ph.D journey, and helping me to shape my earlier works into a
tangible outcome. Thank you Wasana for your unconditional support and
help with my thesis, thank you for patiently reviewing my work and guiding
me how to improve it, and for caring. Thank you Jan for your help in shap-
ing up my ideas and your continuous constructive feedback all along the way.
Special thanks to my previous supervisor Dr David Edmond without
whom I would not be writing these lines. Thank you David for being a
mentor, being a friend, and being there when I needed you, thank you for
your support during the hardest time of my life, thank you for pushing me
to keep going and fight it through.
Part of this research was conducted in the context of the REDCONE
project, an Australian Research Council SPIRT Grant entitled “Self de-
scribing transactions operating in a large, heterogeneous, distributed envi-
ronment”. This project was a collaboration between GBST Holdings Pty
Ltd, the Queensland University of Technology, and the University of New
South Wales. I am grateful for the support provided to me by the grant and
GBST.
A warm thank you to special friends and colleagues who have pro-
vided guidance and support; Guy Redding, Jamie Cornes, Justin O’Sullivan,
X
Rachael Moore, and Moe Thandar Wynn.
A very big thank you to my partner Steven. Thank you for your under-
standing of the importance of this personal journey to me. Thank you for
unconditional love and support, thank you for patiently proof reading my
work chapter by chapter and providing valuable feedback.
Last, but most importantly, I need to thank my dearest friend Dr Phillipa
Oaks who has been with me all the way. Thank you for pushing me to take
up this journey. Thank you for your tremendous support - emotionally &
intellectually. Thank you for your guidance and valuable feedback all along
the way, for sitting there patiently and listening to my crazy research ideas
for many hours. Thank you for helping me to stand up on my feet again
when life was tough. Thank you Phillipa for being Phillipa.
I would like also to thank the rest of my family, my loving brothers,
sister and nephew. I am grateful for all the encouragement, love, support
and motivation I have received over the years.
XI
Abstract
Business Process Management (BPM) has emerged as a popular manage-
ment approach in both Information Technology (IT) and management prac-
tice. While there has been much research on business process modelling and
the BPM life cycle, there has been little attention given to managing the
quality of a business process during its life cycle. This study addresses this
gap by providing a framework for organisations to manage the quality of
business processes during different phases of the BPM life cycle.
This study employs a multi-method research design which is based on the
design science approach and the action research methodology. During the
design science phase, the artifacts to model a quality-aware business process
were developed. These artifacts were then evaluated through three cycles of
action research which were conducted within three large Australian-based
organisations.
This study contributes to the body of BPM knowledge in a number of
ways. Firstly, it presents a quality-aware BPM life cycle that provides a
framework on how quality can be incorporated into a business process and
subsequently managed during the BPM life cycle. Secondly, it provides a
framework to capture and model quality requirements of a business process
as a set of measurable elements that can be incorporated into the business
process model. Finally, it proposes a novel root cause analysis technique for
determining the causes of quality issues within business processes.
Keywords: Business Process Management, BPM life cycle, quality, root
cause analysis
XII
STATEMENT OF ORIGINAL AUTHORSHIP I hereby declare that, to the best of my knowledge and belief, this thesis entitled “Quality-aware Business Process Management” is my own original work. The work contained in this thesis has not been previously been submitted to meet requirements for an award at this or any other higher education institution. Due acknowledgement to each significant contribution to, and quotation in this thesis from the work, or works of other people has been made through the proper use of citations and references.
Mitra Heravizadeh
November 2009.
XIV
Contents
1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1 Research Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1.1 Goal and Objective of the Research . . . . . . . . . . . . . . . . . 2
1.1.2 Research Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2 The Research Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3 Anticipated Research Contributions . . . . . . . . . . . . . . . . . . . . . . 8
1.4 Potential Limitations of the Research . . . . . . . . . . . . . . . . . . . . . 10
1.5 Chapter Summary and Thesis Structure . . . . . . . . . . . . . . . . . . 11
Part I Research Strategy
2 Research Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.1 Chapter Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.2 Business Process Management . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.2.1 Definition of Business Process . . . . . . . . . . . . . . . . . . . . . . 19
2.2.2 History of Business Process Management . . . . . . . . . . . . . 20
2.2.3 Definition of Business Process Management . . . . . . . . . . 21
2.2.4 Summary of Business Process Management . . . . . . . . . . . 24
2.3 Quality Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.3.1 Definition of Quality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.3.2 History of Quality Management . . . . . . . . . . . . . . . . . . . . . 25
2.3.3 History of Quality Management in the Business
Process Area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.3.4 Summary of Quality Management . . . . . . . . . . . . . . . . . . . 31
2.4 A Quality Management Model for BPM . . . . . . . . . . . . . . . . . . . 31
2.5 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
XVI Contents
3 Research Approach and Methodology . . . . . . . . . . . . . . . . . . . . 35
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.2 Research Approach and Methodology Selection . . . . . . . . . . . . 35
3.3 Design Science Paradigm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.4 Action Research Paradigm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.5 Research Design - Multi-Method Approach . . . . . . . . . . . . . . . . 40
3.6 Relation to IS Research Guidelines . . . . . . . . . . . . . . . . . . . . . . . 45
3.7 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Part II Design Science Phase
4 The Design Science Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.2 Quality-aware BPM Life Cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.3 Quality Definition Phase - QoBP Framework Part I . . . . . . . . 56
4.3.1 Quality Models in Related Domains . . . . . . . . . . . . . . . . . 59
4.3.1.1 Literature Review on Software Engineering . . . . 62
4.3.1.2 Literature Review on Services and Web-Services 64
4.3.1.3 Literature Review on Data & Information
Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
4.3.1.4 Literature Review on Human Resource (HR) . . . 68
4.3.2 QoBP Framework - Quality Model . . . . . . . . . . . . . . . . . . 69
4.3.2.1 Function Quality Dimension . . . . . . . . . . . . . . . . . 70
4.3.2.2 Input and Output Quality . . . . . . . . . . . . . . . . . . . 72
4.3.2.3 Human Resource Quality . . . . . . . . . . . . . . . . . . . . 75
4.3.2.4 Non-human Resource Quality . . . . . . . . . . . . . . . . 76
4.3.3 Summary of QoBP Framework Part I . . . . . . . . . . . . . . . . 78
4.4 Quality Definition Phase - QoBP Framework Part II . . . . . . . . 80
4.4.1 Goal-driven Measurement Approach . . . . . . . . . . . . . . . . . 81
4.4.1.1 Literature Review on Measurement Approaches 83
4.4.1.2 Summary of Goal-driven Measurement Approach 92
4.4.2 QoBP Framework - Softgoal Model . . . . . . . . . . . . . . . . . 94
4.4.3 QoBP Framework - Softgoal Correlation Model . . . . . . . 95
4.4.4 QoBP Framework - Measurement Model . . . . . . . . . . . . . 97
4.4.5 Quality-aware EPC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
4.4.5.1 EPC Metamodel . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Contents XVII
4.4.5.2 QoBP Framework - QoBP Metamodel . . . . . . . . . 103
4.4.6 QoBP Framework - QoBP Methodology . . . . . . . . . . . . . 106
4.4.6.1 Analyse the Business Process . . . . . . . . . . . . . . . . 107
4.4.6.2 Create the Business Process Model . . . . . . . . . . . 108
4.4.6.3 Create a Quality Model . . . . . . . . . . . . . . . . . . . . . 110
4.4.6.4 Create a Softgoal Model . . . . . . . . . . . . . . . . . . . . . 111
4.4.6.5 Create a Correlation Model . . . . . . . . . . . . . . . . . . 112
4.4.6.6 Create a Measurement Model . . . . . . . . . . . . . . . . 113
4.4.7 Summary of QoBP Framework Part II . . . . . . . . . . . . . . . 115
4.5 Quality Improvement - PRCA . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
4.5.1 A Background on Root Cause Analysis . . . . . . . . . . . . . . 119
4.5.2 Process Root Cause Analysis (PRCA) Technique . . . . . . 121
4.5.2.1 An Illustration of the PRCA Technique . . . . . . . 124
4.5.2.2 PRCA Technique - A Brief Reflection . . . . . . . . . 126
4.5.3 Summary of Quality Improvement - PRCA Section . . . . 127
4.6 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Part III Action Research Phase
5 Action Research Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
5.2 Selection of Organisations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
5.3 Action Research Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
5.3.1 Initial Engagement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
5.3.2 Diagnosis Stage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
5.3.3 Action Planning Stage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
5.3.4 Action Taking Stage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
5.3.4.1 Action Taking Stage - Phase I . . . . . . . . . . . . . . . . 136
5.3.4.2 Action Taking Stage - Phase II . . . . . . . . . . . . . . . 154
5.3.5 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
5.3.6 Specifying Learning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
5.3.7 Closure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
5.4 Action Research Cycle Report Structure . . . . . . . . . . . . . . . . . . 159
5.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
XVIII Contents
6 First Action Research Cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
6.2 Description of the Organisation . . . . . . . . . . . . . . . . . . . . . . . . . . 162
6.3 Justifications for the Choice of the Organisation . . . . . . . . . . . . 163
6.4 Action Research Cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
6.4.1 Initial Meeting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
6.4.2 Diagnosis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
6.4.3 Action Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
6.4.4 Action Taking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
6.4.4.1 Step 1 - Analyse the Business Process . . . . . . . . . 168
6.4.4.2 Step 2 - Create Business Process Model . . . . . . . 170
6.4.4.3 Step 3 - Create a Quality Model . . . . . . . . . . . . . . 173
6.4.4.4 Step 4 - Create Softgoal Model . . . . . . . . . . . . . . . 189
6.4.4.5 Step 5 - Create Softgoal Correlations Model . . . . 189
6.4.4.6 Step 6 - Create Measurement Model . . . . . . . . . . 190
6.4.5 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
6.4.6 Specifying Learning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
6.4.7 Closure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
6.5 A Reflection on Action Research Cycle and Re-design . . . . . . . 196
6.5.1 Establish Link Between Quality Dimensions . . . . . . . . . . 197
6.5.2 QoBP Automation Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
6.5.3 Reduce Data Collection for Large Business Processes . . 199
6.6 Summary of the First Action Research Cycle . . . . . . . . . . . . . . 200
7 Second Action Research Cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
7.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
7.2 Description of the Organisation . . . . . . . . . . . . . . . . . . . . . . . . . . 202
7.3 Justifications for the Choice of the Organisation . . . . . . . . . . . . 202
7.4 Action Research Cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
7.4.1 Initial Meeting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
7.4.2 Diagnosis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
7.4.3 Action Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
7.4.4 Action Taking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
7.4.4.1 Step 1 - Analyse the Business Process . . . . . . . . . 208
7.4.4.2 Step 2 - Create Business Process Model . . . . . . . 210
7.4.4.3 Step 3 - Create a Quality Model . . . . . . . . . . . . . . 212
Contents XIX
7.4.4.4 Step 4 - Create Softgoal Model . . . . . . . . . . . . . . . 224
7.4.4.5 Step 5 - Create Softgoal Correlations Model . . . . 224
7.4.4.6 Step 6 - Create Measurement Model . . . . . . . . . . 225
7.4.5 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
7.4.6 Specifying Learning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
7.4.7 Closure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
7.5 A Reflection on Action Research Cycle and Re-design . . . . . . . 230
7.5.1 Create a Generic Softgoal Model . . . . . . . . . . . . . . . . . . . . 230
7.5.2 QoBP Automation Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
7.6 Summary of the Second Action Research Cycle . . . . . . . . . . . . 231
8 Third Action Research Cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
8.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
8.2 Description of the Organisation . . . . . . . . . . . . . . . . . . . . . . . . . . 233
8.3 Justifications for the Choice of the Organisation . . . . . . . . . . . . 234
8.4 Action Research Cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
8.4.1 Initial Meeting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
8.4.2 Diagnosis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
8.4.3 Action Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
8.4.4 Action Taking - Phase I . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
8.4.4.1 Step 1 - Analyse the Business Process . . . . . . . . . 240
8.4.4.2 Step 2 - Create Business Process Model . . . . . . . 242
8.4.4.3 Step 3 - Create a Quality Model . . . . . . . . . . . . . . 244
8.4.4.4 Step 4 - Create Softgoal Model . . . . . . . . . . . . . . . 255
8.4.4.5 Step 5 - Create Softgoal Correlations Model . . . . 255
8.4.4.6 Step 6 - Create Measurement Model . . . . . . . . . . 256
8.4.5 Action Taking - Phase II . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
8.4.6 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
8.4.7 Specifying Learning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265
8.4.8 Closure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
8.5 Summary of the Third Action Research Cycle . . . . . . . . . . . . . . 266
8.6 Summary of the Action Research Phase (Part III) . . . . . . . . . . 266
9 Research Contributions, Limitations and Outlook . . . . . . . . 269
9.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
9.2 Re-visiting Research Questions . . . . . . . . . . . . . . . . . . . . . . . . . . 270
XX Contents
9.3 Contributions and Implications . . . . . . . . . . . . . . . . . . . . . . . . . . 274
9.3.1 Implications for Research . . . . . . . . . . . . . . . . . . . . . . . . . . 274
9.3.2 Implications for practice . . . . . . . . . . . . . . . . . . . . . . . . . . . 276
9.4 Research Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
9.5 Future Research . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279
9.6 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
Contents XXI
Appendices
Appendix A.1 Business Process Modelling Notations 290
Appendix A.2 Root Cause Analysis Techniques 299
Appendix B.1 Meeting Agenda Template 312
Appendix B.2 Meeting Notes Templates 313
Appendix B.3 Invitation Letter 315
Appendix B.4 Action Research Project Summary 316
Appendix B.5 Evaluation Questions 322
Appendix C.1 Organisation A - Functions Softgoal Model 325
Appendix C.2 Organisation A - Input & Output Softgoal Model 327
Appendix C.3 Organisation A H Resource Softgoal Model 342
Appendix C.4 Organisation A N H Resource Softgoal Model 344
Appendix C.5 Organisation A Softgoal Correlation Model 346
Appendix C.6 Organisation A Function Measurement Model 350
Appendix C.7 Organisation A Input & Output Measurement Model 357
Appendix C.8 Organisation A - H Resource Measurement Model 405
Appendix C.9 Organisation A N H Resource Measurement Model 410
Appendix C.10 QoBP Automation Tool 418
Appendix D.1 Organisation B Functions Softgoal Model 431
Appendix D.2 Organisation B Input & Output Softgoal Model 433
Appendix D.3 Organisation B H Resource Softgoal Model 439
Appendix D.4 Organisation B N H Resource Softgoal Model 441
Appendix D.5 Organisation B Softgoal Correlation Model 442
Appendix D.6 Organisation B Function Measurement Model 444
Appendix D.7 Organisation B Input & Output Measurement Model 448
Appendix D.8 Organisation B - H Resource Measurement Model 466
Appendix D.9 Organisation B N H Resource Measurement Model 471
Appendix E.1 Organisation C Functions Softgoal Model 474
Appendix E.2 Organisation C Input & Output Softgoal Model 475
Appendix E.3 Organisation C H Resource Softgoal Model 478
Appendix E.4 Organisation C N H Resource Softgoal Model 479
Appendix E.5 Organisation C Softgoal Correlation Model 480
XXII Contents
Appendix E.6 Organisation C Function Measurement Model 481
Appendix E.7 Organisation C Input & Output Measurement Model 483
Appendix E.8 Organisation C H Resource Measurement Model 491
Appendix E.9 Organisation C N H Resource Measurement Model 497
Appendix E.10 Organisation C 1st Incident Management Instance 500
Appendix E.11 Organisation C 2nd Incident Management Instance 503
List of Figures
1.1 BPM Quality Management Model . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Quality-aware Business Process Management Life Cycle . . . . . 6
1.3 Research Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.4 Thesis Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.1 Summary of the Literature Review Areas . . . . . . . . . . . . . . . . . 18
2.2 Business Process Management Life Cycle [1] . . . . . . . . . . . . . . . 22
2.3 BPM Quality Management Model . . . . . . . . . . . . . . . . . . . . . . . 33
3.1 Information Systems Research Framework as defined by
Hevner et al. [2] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.2 The Action Research Cycle [3] . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.3 Research methodology of a design-based research study
using action research . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.4 Research Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.1 Research Questions & Proposed Artifacts . . . . . . . . . . . . . . . . . 50
4.2 Quality-aware Business Process Management Life Cycle . . . . . 53
4.3 Quality Definition Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.4 QoBP Framework - Quality Model - Quality Dimensions of
Business Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.5 Business Process Quality Dimensions - Literature Review
Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.6 QOBP Quality Dimensions & Characteristics . . . . . . . . . . . . . . 79
4.7 GQM in the QoBP Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 99
4.8 Horizontal Levels of Abstractions of a Business Process [4] . . 101
4.9 EPC Metamodel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
XXIV List of Figures
4.10 QoBP Metamodel as a UML class diagram . . . . . . . . . . . . . . . . 104
4.11 Request for proposals process of the software house . . . . . . . . 109
4.12 An Example for Softgoal Correlations Model . . . . . . . . . . . . . . 114
4.13 Quality Improvement Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
4.14 QoBP Metamodel - PRCA as a UML class diagram . . . . . . . . 122
4.15 An Example for Softgoal Correlations Model . . . . . . . . . . . . . . 125
5.1 Action Research Engagement Plan . . . . . . . . . . . . . . . . . . . . . . . 134
5.2 Function Quality Dimension (captured as yes or no) . . . . . . . 140
5.3 Function Quality Dimension (by rows - quality characteristics)140
5.4 Function Quality Dimension (by columns - quality
characteristics) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
5.5 Input & Output Quality Dimension . . . . . . . . . . . . . . . . . . . . . . 144
5.6 Human Resource Quality Dimension . . . . . . . . . . . . . . . . . . . . . 145
5.7 Non-Human Resource Quality Dimension (captured as yes
or no) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
5.8 Non-Human Resource Quality Dimension (by rows - quality
characteristics) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
5.9 Non-Human Resource Quality Dimension (by columns -
quality characteristics) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
5.10 Function Softgoals Template . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
5.11 Input & Output Softgoals Template . . . . . . . . . . . . . . . . . . . . . . 150
5.12 Human Resource Softgoals Template . . . . . . . . . . . . . . . . . . . . . 150
5.13 Non-Human Resource Softgoals Template . . . . . . . . . . . . . . . . . 151
5.14 Softgoals Correlation Template . . . . . . . . . . . . . . . . . . . . . . . . . . 152
5.15 Function Measurement Model Template . . . . . . . . . . . . . . . . . . 153
5.16 Input & Output Measurement Template . . . . . . . . . . . . . . . . . . 153
5.17 Human Resource Measurement Template . . . . . . . . . . . . . . . . . 153
5.18 Non-Human Resource Measurement Template . . . . . . . . . . . . . 154
5.19 Process Root Cause Analysis (PRCA) Template . . . . . . . . . . . 155
6.1 Plan for the Action Taking Phase . . . . . . . . . . . . . . . . . . . . . . . . 167
6.2 Claim Intake Process EPC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
6.3 Claim Intake Process - Function Quality Dimension
(captured as yes or no) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
6.4 Claim Intake Process - Functions Quality Rating . . . . . . . . . . . 176
List of Figures XXV
6.5 Claim Intake Process - Quality Characteristics . . . . . . . . . . . . . 177
6.6 Function Quality Dimension (by functions - columns) . . . . . . . 178
6.7 Claim Intake Process - Quality Rating by Functions . . . . . . . . 178
6.8 Function Quality Dimension (by rows - quality characteristics)179
6.9 Claim Intake Process - Quality Rating . . . . . . . . . . . . . . . . . . . . 180
6.10 Claim Intake Process - Input & Output Quality Dimension . . 181
6.11 Claim Intake Process - Human Resource Quality Dimension . 182
6.12 Claim Intake Process - Human Resource Quality Rating . . . . 184
6.13 Claim Intake Process - Quality Characteristics . . . . . . . . . . . . . 184
6.14 Claim Intake Process - Non Human Resource Quality
Dimension (captured as yes or no) . . . . . . . . . . . . . . . . . . . . . . . 185
6.15 Claim Intake Process - Non Human Resource Quality Rating 186
6.16 Claim Intake Process - Non Human Resource Quality
Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
6.17 Claim Intake Process - Non Human Resource Quality
Dimension (by rows - quality characteristics) . . . . . . . . . . . . . . 187
6.18 Claim Intake Process - Non Human Resource Quality Rating 187
6.19 Claim Intake Process - Non Human Quality Dimension (by
functions - columns) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
6.20 Claim Intake Process - Quality Rating by Non Human
Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
6.21 Function - Input & Output Quality Characteristics Matrix . . 197
7.1 Plan for the Action Taking Phase . . . . . . . . . . . . . . . . . . . . . . . . 207
7.2 Dynamic Development Process EPC . . . . . . . . . . . . . . . . . . . . . 211
7.3 Dynamic Development Process - Function Quality
Dimension (captured as yes or no) . . . . . . . . . . . . . . . . . . . . . . . 214
7.4 Dynamic Development Process - Functions Quality Rating . . 215
7.5 Dynamic Development Process - Quality Characteristics . . . . 215
7.6 Function Quality Dimension (by functions - columns) . . . . . . . 216
7.7 Claim Intake Process - Quality Rating by Functions . . . . . . . . 217
7.8 Function Quality Dimension (by rows - quality characteristics)217
7.9 Dynamic Development Process - Quality Rating . . . . . . . . . . . 218
7.10 Dynamic Development Process - Input & Output Quality
Dimension (Before Validation) . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
XXVI List of Figures
7.11 Dynamic Development Process - Input & Output Quality
Dimension (After Validation) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
7.12 Dynamic Development Process - Human Resource Quality
Dimension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
7.13 Dynamic Development Process - Human Resource Quality
Rating . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
7.14 Dynamic Development Process - Quality Characteristics . . . . 222
7.15 Dynamic Development Process - Non Human Resource
Quality Dimension (by rows - quality characteristics) . . . . . . . 223
7.16 Dynamic Development Process - Non Human Resource
Quality Rating . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
8.1 Plan for the Action Taking Phase . . . . . . . . . . . . . . . . . . . . . . . . 239
8.2 Incident Management Process EPC . . . . . . . . . . . . . . . . . . . . . . 243
8.3 Incident Management Process - Function Quality Dimension
(captured as yes or no) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
8.4 Incident Management Process - Functions Quality Rating . . . 246
8.5 Incident Management Process - Quality Characteristics . . . . . 247
8.6 Function Quality Dimension (by functions - columns) . . . . . . . 247
8.7 Incident Management Process - Quality Rating by Functions 248
8.8 Function Quality Dimension (by rows - quality characteristics)249
8.9 Incident Management Process - Quality Rating . . . . . . . . . . . . 249
8.10 Incident Management Process - Input & Output Quality
Dimension (Before Validation) . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
8.11 Incident Management Process - Input & Output Quality
Dimension (After Validation) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
8.12 Incident Management Process - Human Resource Quality
Dimension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
8.13 Incident Management Process - Human Resource Quality
Rating . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252
8.14 Incident Management Process - Quality Characteristics . . . . . 253
8.15 Incident Management Process - Non Human Resource
Quality Dimension (by rows - quality characteristics) . . . . . . . 254
8.16 Incident Management Process - Non Human Resource
Quality Rating . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
8.17 Softgoal Correlations - Incident Management Process . . . . . . . 258
List of Figures XXVII
8.18 Summary of the Action Research Cycles . . . . . . . . . . . . . . . . . . 267
9.1 Research Questions & Proposed Artifacts . . . . . . . . . . . . . . . . . 271
1
Motivation
The increasing demand to continue to improve, has led organisations to seek
a better understanding of their business processes. Process oriented manage-
ment has been adopted in many organisations to overcome this challenge.
This has led to many innovations in this area over the last few decades, the
latest being Business Process Management (BPM) [5].
Over the last few years, BPM has continuously been identified as a top
business priority for senior executives and building business process capa-
bilities will continue to be a major agenda item for senior executives in the
coming years [6, 7, 8]. The popularity and significance of BPM has led to
much research in the area contributing to successful BPM implementations
in some organisations.
Quality has been an important topic within the business process com-
munity. In this context, process quality refers to the ability of a process to
produce and deliver quality products [9]. The operational benefits of “qual-
ity” often translates into lower operating costs and improved customer sat-
isfaction [10, 11]. Contrary to “quality” being known as one of the essential
business process performance dimensions [12, 13, 14, 9, 15], there is no struc-
tured approach or framework to capture and represent the quality aspects
of a business process1. Frequently, the enactment of a business process is
functionally correct (all the events and functions are enacted in the order
they have been defined), but the outcome is nevertheless unacceptable be-
cause the outcome does not meet some quality criteria such as timeliness
and accuracy. The quality aspects of a business process are often difficult
1 Refer to Section 4.3 for further justifications.
2 1 Motivation
to capture and as a result they are either overlooked or deferred [16].
“Quality management” refers to all the activities that organisations use
to plan, control, coordinate and improve quality. To date, little research at-
tention has been directed at the integration of a quality management model
into BPM. Historically, quality has been addressed by most of the practices
in the area such as Six Sigma [17], Total Quality Management (TQM) [18],
Business Process Re-engineering (BPR) [19, 20, 14], and Business Process
Improvement (BPI) [21]. Over time, each of these practices have incorpo-
rated a quality framework. For example, Sinclair and Zairi [12, 13] have
introduced a quality model for TQM which is based on a series of case
studies [22, 23, 24]. While their proposed model was proven to be a contri-
bution to the area, it is very tightly coupled with the TQM framework and
cannot be integrated with other approaches such as BPR or BPI. Similar
efforts have been underway to incorporate a quality model into the BPR
and BPI life cycles which are also very specific to BPR and BPI. The BPM
community has been rather slow in exploring the integration of a quality
model into BPM. The primary goal of this research is to address this short-
coming. To our knowledge, this is the first systematic study that attempts
to provide a framework for such an integration and to empirically evaluate
the initiative.
1.1 Research Problem
This section describes the research problem this thesis is addressing. The
motivations of this study are discussed in Section 1.1.1, followed by the re-
search questions in Section 1.1.2.
1.1.1 Goal and Objective of the Research
The primary goal of this research is to provide a framework for organisa-
tions to manage the quality of business processes during different phases of
the BPM life cycle. Before discussing the objectives of this research, it is
necessary to briefly clarify the terms “BPM life cycle”, “quality” and “qual-
ity management” (a more detailed description on these terms is provided in
1.1 3
Chapter 2).
The BPM life cycle is important to this research since the quality frame-
work described in this thesis is envisioned to be a complement to BPM.
BPM is simply the process of managing the business processes in an organi-
sation. In BPM, management activities related to business processes can be
arranged in a cyclical structure which is referred to as the BPM life cycle.
To date, a number of BPM life cycles have been defined [15, 25, 26, 4, 1].
The BPM life cycle proposed in [1] will be used in this study, because (1)
it includes all the management activities required to successfully manage
the quality of a business process, and (2) it defines all the artifacts required
as input and output for the different phases. The BPM life cycle proposed
in [1] consists of six phases: analysis, design, implementation, enactment,
monitoring, and evaluation2.
The term “quality” has been given various definitions and interpreta-
tions by different fields and disciplines3. Throughout this thesis, the term
quality relates to the non-functional requirements of a business process such
as accuracy, conformance to specification, and reliability4. This definition
is influenced heavily by Juran’s definition of quality and the ISO standard
[27] definition of quality from the software engineering discipline.
“Quality management”, in general, refers to all the activities that or-
ganisations use to plan, control, coordinate and improve quality. To date, a
number of “quality management” models have been defined5. While there
are some differences between these models, there are many common fea-
tures. The quality management model proposed in this thesis is an exten-
sion of the quality trilogy proposed by Juran6 [28]. Juran’s quality trilogy is
a universal quality management model based on three key steps of quality
2 Refer to Section 2.2.3 for further details on each phase.3 Refer to Section 2.3.1 of chapter 4.4 for the definition of quality in different disciplines.4 The focus of this research is on the quality of a business process which is different with thequality of a business process model (see Section 2.3.1 for further details).
5 Refer to Section 2.3.2 for a brief history of quality management models.6 Joseph Juran is an internationally acclaimed quality expert, who is well known for his con-tribution to Japanese manufacturing practices (www.mftrou.com/joseph-juran.html). Referto Section 2.3.2 for a literature review of other quality management models and reasons foradopting Juran’s quality trilogy model.
4 1 Motivation
planning, quality control, and quality improvement. He describes each step
as a process that is carried out by a homogeneous sequence of activities.
Quality planning is a preparation process that takes place to meet quality
goals during production. Quality control is a process that takes place to en-
sure quality goals are met during operations (ensuring the operations are in
accordance with the quality plan). Quality improvement is the process that
takes place for the purpose of breaking through to unprecedented levels of
performance. Juran’s quality management model is adopted for this study,
because its quality management activities are arranged in a cyclical struc-
ture and its key phases can be extended to match the phases of the BPM
life cycle. Juran’s quality management model is extended in this thesis by
replacing the quality planning phase with two distinct phases: quality defi-
nition, and quality implementation. Figure 1.1 depicts the proposed quality
management model which consists of four key phases: quality definition,
quality implementation, quality control and quality improvement. This qual-
ity management model is the outcome of the investigation conducted during
the early stages of this study. A more detailed description of this quality
management model is provided in Section 2.3.4.
Quality Definition
Quality Control
Quality Improvement
Quality Implementation
Fig. 1.1. BPM Quality Management Model
The main objective of this research is to incorporate the quality manage-
ment model depicted in figure 1.1 into the BPM life cycle. This objective
1.1 5
is achieved by providing a framework that facilitates the integration of the
four key phases of the quality management model (quality definition, quality
implementation, quality control and quality improvement) into the business
process life cycle. This framework should facilitate:
• quality definition of a business process - producing a business process
that is quality-aware;
• implementation of a quality-aware business process;
• quality control of a business process; and,
• quality improvement of a business process.
1.1.2 Research Questions
In this study, the research questions are derived based on the approach
suggested in [29] and [30]. In this approach, the research questions are for-
mulated in a hierarchical approach which comprises four levels. Level 1, the
highest level in the hierarchy is referred to as the ‘managerial question’. The
managerial question is used to express the main research problem. Level 2
presents the main research questions that are derived from the managerial
question. Level 3 presents the investigation questions. The investigation
questions guide the details of the research effort [29]. The lowest level of the
hierarchy, level 4, presents the measurement questions. This section presents
the questions related to the tops 3 levels. The level 4 questions are presented
in Appendix B.5 (as part of the questionnaire provided to guide the evalu-
ation process - see Section 5.3.5).
The managerial question driving this study is:
How can organisations manage the quality of business processes during
the different phases of the BPM life cycle?
As defined before, in this research, quality relates to the non-functional
requirements of a business process. Accordingly, the managerial question is
6 1 Motivation
refined to the main research question that captures the general purpose of
this study. The main research question that needs to be addressed to pro-
vide a solution for the managerial question above is:
How can quality be incorporated into a business process and
managed during the BPM life cycle?
A comprehensive literature review (see Section 2) was conducted to es-
tablish the context for describing and elaborating the main research ques-
tion. This led to a proposal for a quality-aware BPM life cycle in which a
quality management model is incorporated into the BPM life cycle. Figure
1.2 presents the proposed quality-aware BPM life cycle in which the pro-
posed quality management model (see Section 1.1.1) is incorporated into
the BPM life cycle defined in [1]. The development of this model was a nec-
essary step to define the research questions and the scope of this study in a
structured approach. In the quality-aware BPM life cycle, the quality of a
business process is managed based on the four key phases:quality definition,
quality implementation, quality control and quality improvement7.
Analysis
Design
Implementation
Enactment
Monitoring
Evaluation
Business Process Requirements & Quality Requirements
Quality Aware Business Process Model
Implemented Quality Aware ProcessProcess & Quality Metrics
Measures for Improvements
Measurements
Process & Quality Metrics
Quality Improvement
Quality Definition
Quality Implementation
Quality Control
Fig. 1.2. Quality-aware Business Process Management Life Cycle
7 Refer to Section 4.2 for further details on these four phases.
1.2 The Research Strategy 7
The scope of this thesis is limited to the quality definition and quality
improvement phases of the quality-aware BPM life cycle. Quality definition
and quality improvement are the two key phases that influence the identifi-
cation and modelling of the quality aspects of a business process. Therefore,
the investigation questions pertaining to the main research question are fo-
cused on these two phases:
1. Quality definition phase:
a) What are the business process quality dimensions?
b) How can quality be incorporated into a business process model pro-
ducing a quality-aware business process?
2. Quality improvement phase:
a) What is a suitable technique for identifying the root causes of the
quality issues of a business process?
Figure 1.3 summarises the research questions.
1.2 The Research Strategy
This study employs a multi-method research design utilising the design sci-
ence approach and action research methodology. This utilisation was chosen
for this research with the aim of “delivering practical value to the subject
while at the same time contributing to theory” [31]. The solution concepts
that were developed using a design science paradigm were tested in real life
situations using the action research paradigm. A multi-method approach,
which is based on both the IS research framework [2] and the design-based
research approach by [32], is adopted for this research. A more detailed out-
line of the research strategy is presented in Chapter 3.
8 1 Motivation
How can a quality management framework be incorporated into the BPM life cycle?
Quality-Aware BPM Life CycleQuality Definition
Ξ What are the business process quality dimensions?
Ξ How can quality be incorporated into a business process model producing a quality-aware business process?
Part II Chapter 4
Part IIChapter 4
Quality Management Life CycleQuality Improvement
Ξ What is a suitable technique for identifying the root causes of the quality issues of a business process?
Quality-Aware BPM Life Cycle
Fig. 1.3. Research Questions
1.3 Anticipated Research Contributions
This is the first in-depth study that attempts to define and integrate a suit-
able quality management model into the Business Process Management life
cycle. The contributions of this study can be classified as both theoretical
and practical :
• Theoretical Contributions - the contributions derived from the study
that can be used by new researchers:
– The quality-aware BPM life cycle (see Section 4.2) that provides the
framework to manage the quality of a business process through its life
cycle.
– A validated quality model (see Section 4.3) for a business process that
describes the quality requirements of a business process in the form
of quality characteristics which are related to four dimensions of the
1.3 Anticipated Research Contributions 9
business process (function, input & output, human resource and non-
human resource).
– A validated framework (QoBP framework - see Sections 4.3 & 4.4)
that supports the creation of quality-aware business process models.
This framework provides a systematic and novel goal-driven approach
to incorporate the quality requirements of a business process into
a business process model during the quality definition phase of the
quality-aware BPM life cycle.
– A validated, novel root cause analysis approach (PRCA technique -
see Section 4.5) for business processes. This root cause analysis tech-
nique provides a systematic and consistent approach to identify the
root causes of a quality issue in an instance of a business process.
– An exemplar on how a multi-method research design utilising design
science approach and action research methodology can be conducted
in Information Systems research.
– An exemplar of how a staged approach to defining the research ques-
tions can be used to define and control the scope of research.
– An exemplar of how an action research protocol can be defined and
applied across the action research cycles to conduct rigorous action
research.
– An exemplar of how to evaluate research that is based on the design
science approach in relation to the Information Systems (IS) research
guidelines provided by [2].
• Practical Contributions - the contributions derived from the study
that can be directly adopted by organisations:
– A validated framework (see Chapter 4) that can be adopted by organ-
isations to manage quality of their business processes during different
10 1 Motivation
phases of the BPM life cycle. The adoption of this framework will help
organisations to:
· Identify the quality requirements with regards to all dimensions
of their business processes (such as functions, inputs & outputs,
human resources, and non-human resources).
· Embed their quality requirements into the business process models
- producing quality-aware business process models.
· Improve the quality of their business processes by identifying the
root causes of the quality issues in instances of those processes.
– A quality metamodel for business process modeling notations that
can be adopted by business process modeling vendors to extend their
modeling tools to support modeling of quality-aware business process
models (see Section 4.4.5.2).
1.4 Potential Limitations of the Research
The purpose of this section is to outline the potential limitations of this
study which include:
• Limitations in the literature review phase - The early literature review
was conducted to establish the context for describing and elaborating
the research problem leading to a proposal for a quality-aware BPM life
cycle8. Introduction of the quality-aware BPM life cycle generated sev-
eral research questions and addressing them all was beyond the scope of
this thesis. The scope of this research definition was made based on the
criticality of the research questions that needed to be addressed to solve
the original problem identified.
• Limitations in the design science phase - The limitation of the design
science phase of this study was the development of artifacts to address
8 Refer to Section 4.2 for further details on the quality-aware BPM life cycle.
1.5 Chapter Summary and Thesis Structure 11
the research questions without a proper evaluation prior to the action
research phase. The evaluation of these artifacts was intended to occur
during the action research phase of this study. The risks associated with
this limitation is a major re-work (re-design) of the developed artifacts
during the action research phase.
• Limitation in the action research phase - As the selection of host organ-
isations for the action research cycles was constrained by budgetary and
accessibility issues, all the organisations selected were Australian and
were located in Queensland.
An extensive effort is made during this research to mitigate the risks
associated with these limitations9.
1.5 Chapter Summary and Thesis Structure
In this chapter, the importance of incorporating a quality framework into
the Business Process Management life cycle was discussed. The research
problem was presented followed by the research strategy for this study and
anticipated contributions. The remainder of this thesis is structured into
three parts. An introduction is included at the beginning of each part to
provide the background to, and overview of the concepts discussed in that
part. Figure 1.4 depicts the overall thesis structure.
Part I:
Part I consists of two chapters. In Chapter 2, the relevant literature is
reviewed to establish the context of the research presented in this thesis.
Chapter 3 presents the epistemological and theoretical foundations of this
research, and the details of the multi-method design applied in this study.
Part II:
Part II of this thesis consists of one chapter (Chapter 4) which is dedicated
to the design phase of this study. Chapter 4 presents the artifacts developed
9 Refer to Section 9.4 for further details on these limitations.
12 1 Motivation
Chapter 1
Par
t I
Res
earc
h S
trat
egy
Par
t II
Des
ign
S
cien
ce
Ph
ase
Par
t III
Act
ion
Res
earc
h P
has
e
Chapter 4
Chapter 3
Chapter 2
Introduction
Research Background
Research Methodology
The Design Science Phase
Chapter Structure
Chapter 5
Chapter 6
Chapter 7
Chapter 8
Action Research Protocol
Action Research Case One
Action Research Case Two
Action Research Case Three
Research Contributions & LimitationsChapter 9
Fig. 1.4. Thesis Structure
by this thesis to address the research questions outlined in Section 1.1.2.
Part III:
Part III is dedicated to the action research phase of this study and consists
of four chapters. The first chapter (Chapter 5) presents a protocol that is
designed by this study to evaluate the developed artifacts during the ac-
1.5 Chapter Summary and Thesis Structure 13
tion research cycles. The subsequent three chapters (Chapters 6, 7, and 8
present three action research cycles that are conducted as part of this study.
Chapter 9 provides a summary of the study, highlighting the key con-
tributions, and limitations, as well as some recommendations for future
research.
Part I
Research Strategy
2
Research Background
2.1 Chapter Introduction
Conducting a review of prior and relevant literature is an essential part of
any academic research [33], as it (1) creates a firm foundation for advancing
knowledge by uncovering areas where research is required, and (2) ensures
that this foundation is built on the existing body of knowledge leading to
consistency and avoidance of redundancy. A literature review is usually an
ongoing activity during the life of the research and this study is no exception.
The literature review presented in this chapter is dedicated to providing the
overall background for this research. Literature reviews are presented at the
beginning of the subsequent chapters throughout this thesis to provide more
specific information on each topic. Table 2.1 presents how the continuous
literature review took place within this study.
The literature review presented in this chapter serves three aims:
1. To establish the context of the research presented in this thesis. The
study presented in this thesis relates to research on managing quality of
business processes. Hence, two areas - BPM & quality - are introduced
in sections 2.2 and 2.3.
2. To provide a context for describing and elaborating the problem being
identified [34]. The purpose here was to reveal the problem, which is
“how can organisations manage the quality of the business processes
during different phases of the BPM life cycle?”. Accordingly, a history
of quality management in business process trends prior to BPM (such
18 2 C h ap ter R ev iew ed L iteratu re
A rea P u rp o se Chapter 3 Research M ethods To provide an o verview on research m ethods. Chapter 4 D esign Science Research M ethodology To provide an o verview on design science research m ethodolo gy. Chapter 4 Q ua lity To rev iew how qua lity is defined in re levant d iscip lines. Chapter 4 G oa l M odeling To provide an o verview of literature on go al m odeling techniques used in Requirem ent Engineering. Chapter 4 & A ppendix A Root Cause A nalysis To rev iew the literature on d ifferent root cause analysis techniques. Chapter 5 A ppendix A A ction Research M ethodology Business Pro cess M o deling N otations To provide an o verview on action research m ethodo logy. To rev iew business process m odeling notations capab ility in m odeling quality requirem ents.
Fig. 2.1. Summary of the Literature Review Areas
as BPI and BPR) is presented in Section 2.3.3. A historical presenta-
tion here serves two purposes: (1) it provides a historical account of the
development of quality frameworks in the area as a confirmation of the
importance of managing quality; and (2) it highlights the lack of a qual-
ity management model for BPM.
3. To develop a quality management model that is suitable for BPM by
examining existing quality management models [34]. Consequently, the
quality management models introduced and widely adopted by organisa-
tions over the last century are examined and presented in chronological
order in Section 2.3.2.
2.2 Business Process Management
The literature in the area of business processes and BPM will be exam-
ined in this section. This section first establishes a working definition of the
terms “business process” and “Business Process Management”. It contin-
2.2 Business Process Management 19
ues by looking into the historical origins and evolution of Business Process
Management.
2.2.1 Definition of Business Process
A large number of definitions exist for the term ‘business process’ across
the literature. Lindsay, Downs and Lunn [35] acknowledge the lack of a
commonly accepted definition. For example, the founders of BPR in the
1990s have different views on the definition of business process. Hammer
& Champy [14] define business process as “a collection of activities that
takes one or more kinds of input and creates an output that is of value
to the customer. A business process has a goal and is affected by events
occurring in the external world or in other processes”. The definition by
Davenport & Short [20] is slightly different as they see a business process
as “simply a structured set of activities designed to produce a specified out-
put for a particular customer or market”. These definitions vary as they
focus on different aspects of a business process. Hammer & Champy’s def-
inition has a strong focus on the inputs & outputs of a business process,
while Davenport’s definition has more emphasis on the association of the
outcome of a business process with a requester of a product. A variety of
other definitions can be found in the literature, however all of them cover
similar characteristics indicated in the above definitions. The definition by
[4] seems to be the most complete definition among them as it encapsulates
all the major elements of a business process: “A business process consists
of a set of activities that are performed in coordination in an organisational
and technical environment. These activities jointly realise a business goal.
Each business process is enacted by a single organisation, but it may inter-
act with business processes by other organisations.”
In the context of this research, a comprehensive definition of a busi-
ness process consists of all the elements described in the above definitions.
Accordingly, a business process is defined as a set of inter-related activities
that is intended to achieve a business goal by transforming inputs to outputs
that are valuable to a customer or another process; it can be executed by
human or non-human resources and has a clearly defined beginning and end.
20 2
2.2.2 History of Business Process Management
The purpose of this section is to briefly examine the major events, trends
and innovations that have led to the introduction of Business Process Man-
agement (BPM) since the early 1980s.
The introduction of the notion of the Value Chain [36] was a significant
advance in the area. The Value Chain was referred to as the collection of
activities required to transform the given raw materials into a final product.
The support processes such as maintenance and marketing were also part
of the Value Chain concept. At the same time Total Quality Management
(TQM1) and Activity-Based Costing were introduced (during the 1980s).
These three innovations are early examples of a process-focused approach
in management.
The introduction of Business Process Re-engineering (BPR) in the early
1990s by [19, 20, 14], using information technology as the enabler, was an-
other significant development in the area which initiated a major change
to organisations. These authors provided convincing evidence on how or-
ganisations can benefit from proceeding with large process re-engineering
projects, but like many initiatives, the business process re-engineering had
its own limitations. The lack of a coherent methodology for change was
one of its significant limitations [37]. At the same time the authors in [38]
proposed a methodology that provided specific guidelines for the successful
implementation of business process re-engineering projects. Unlike the pro-
posal by [19, 20, 14], their focus was not on IT.
In the late 1990s Business Process Improvement (BPI) was introduced as
a methodology to overcome the limitation of the BPR approach. Business
Process Improvement is simply the process by which incremental changes
are introduced in a process for the purpose of improvement. Harrington, Es-
seling and Nimwegen [21] define Business Process Improvement as a combi-
nation of four different approaches designed to improve efficiency, effective-
ness and adaptability of the business processes. The four BPI approaches
are Fast Analysis Solution Technique (FAST), process benchmarking, pro-
1 Refer to Section 2.3.2 for further details on TQM.
2.2 Business Process Management 21
cess redesign and process re-engineering. In their view, organisations gain
performance improvements by analysing hundreds of activities and tasks
with the aim of optimising the total performance in a short period of time.
Shin and Jemella [39] have categorised process improvements into three
categories: quick hits, incremental improvement, and re-engineering. Quick
hits improvements are typically low risk and easily achievable efforts that
provide immediate payback opportunities. Incremental improvements, how-
ever deliver small degrees of change that introduce small but meaningful
business results. Re-engineering improvements, unlike quick hits and incre-
mental improvement, are forms of organisational change characterised by
dramatic process transformation.
The next initiative was Business Process Management (BPM) by [5]
which promised to be a new revolution in the area of process management
- the third wave of Business Process Management. In the authors opinion,
the first wave was the “methods and procedure analysis” proposed by Tay-
lor’s theory of management [40]. The second wave was the introduction of
BPR followed by the IT implementation of the systems such as Workflow
Management Systems (WMS) and Enterprise Resource Planning Systems
(ERP). The third wave being BPM - the “synthesis and extension of all
these technologies and techniques into a unified whole”. BPM is more than
just discrete improving or re-engineering of processes offered by the earlier
initiatives such as BPR and BPI. It is an integral part of management [41],
promoting an ongoing process improvement. BPM is a strategic business ap-
proach leading to process performances and external customer satisfaction
[42].
2.2.3 Definition of Business Process Management
A definition by Zairi [43] suggests that BPM is “the way in which key busi-
ness activities are managed and continuously improved to ensure consistent
ability to deliver high quality standards of products and services”. In other
words, BPM is simply the process of managing the business processes in an
organisation.
22 2
The management of activities related to business processes can be ar-
ranged in a cyclical structure which is referred to as the BPM life cycle2.
While a number of BPM life cycles have been defined [15, 25, 26, 4], the
BPM life cycle proposed in [1] will be used in this study because: (1) it
includes all the management activities required to successfully manage the
quality of a business process, and (2) it defines all the artifacts required as
input and output for the different phases.
The BPM life cycle proposed by Mendling [1] consists of six phases:
analysis, design, implementation, enactment, monitoring, and evaluation.
A graphical representation of the BPM life cycle by [1] is depicted in figure
2.2. The following paragraphs briefly introduce each phase.
Analysis
Design
Implementation
Enactment
Monitoring
Evaluation
Requirements
Process Model
Implemented ProcessesProcess Metrics
Measures for Improvements
Measurements
Process Metrics
Fig. 2.2. Business Process Management Life Cycle [1]
Analysis - The life cycle begins with an analysis of the organisation
structure, process goals, and the process environment. Understanding the
organisation’s structure, strategy and goals is a vital step. When analysing
the process goals it is important to ensure that they are aligned with the or-
ganisation’s strategy and add value to it. In this phase, the requirements of
2 Refer to Section 1.1.1 for further details on the BPM life cycle.
2.2 Business Process Management 23
a business process are elicited, taking account of the organisation’s strategy,
goals and structure. The output from this phase includes the requirements
description of the business process.
Design - In this phase the overall process structure is engineered based
on the requirements from the analysis phase. The design includes the iden-
tification of the activities of a process, specification of human resources
involved with activities and their role within the organisation, specification
of non-human resources (such as computer systems, printers, projectors etc)
required for activities, and specification of data & information associated
with the activities. The business process is modeled using a business process
modeling technique3. A business process model is an artefact consisting of
a set of activities and the flows between them. Business process models are
the main artifacts for implementing business processes.
Implementation - This phase involves the implementation of the pro-
cess model developed at the design phase. During the implementation phase,
the infrastructure for business process support is established. It involves ac-
tivities such as staff training, technical implementation and configuration of
supporting software (if there is a need), provision of new work place struc-
tures etc.
Enactment - The enactment of a process starts upon completion of the
process implementation. This phase covers the actual run time of the busi-
ness process. During this phase individual instances4 derived from the pro-
cess model are executed using the dedicated infrastructure. The information
produced from this phase is available for subsequent activities, monitoring
and evaluation.
Monitoring - Monitoring is an administrative phase which is bound
to each individual process instance. The main purpose of this activity is
3 Business process modeling notation is a graphical representation of a business process model[4], and a business process model is an abstract description of a business process, and repre-sents selected process elements [44]. Appendix A.1 presents several business process modelingnotations such as Petri nets, EPCs, YAWL, BPMN, and UML Activity Diagram.
4 A business process instance is an instantiated version of a business process model. For examplefor a “claim process”, the “claim process for Mr Brown” is an instance of the “claim process”.
24 2
to visualise the status of business process instances by providing necessary
information about the process instance. The information provided is impor-
tant, for example, in response to a customer request that inquires about the
status of his “insurance claim” process instance. In some cases, other valu-
able execution data such as process performance indicators are gathered.
The process performance indicators are usually identified during analysis &
design phase and are monitored and measured for each individual process
instance during this phase.
Evaluation - In this phase performance data collected during the mon-
itoring phase is evaluated against the original requirements. In some cases
the evaluation results lead to a set of new requirements for the next turn of
the business process management life cycle, or improvement to the planning
of the resource capacity.
In the context of this research, BPM is a set of management activities
aimed at designing, implementing, enacting, controlling, evaluating and im-
proving business processes according to the organisation’s objectives.
2.2.4 Summary of Business Process Management
In this section, a review of literature related to BPM was presented. Working
definitions were developed and examined. The focus of the literature review
was to establish the context of the research presented in this thesis by
informing the reader of the state of knowledge in this area at the time of
the writing of this thesis, and to justify the value of this thesis and its
contribution to knowledge.
2.3 Quality Management
The literature in the area of quality management will be examined in this
section. This examination takes place by first establishing a working defini-
tion of the term “quality” within the context of this study. Then, it continues
by looking into the historical evolution of quality management models in
general, and a history of quality management in business process trends
prior to BPM (such as BPI and BPR).
2.3 Quality Management 25
2.3.1 Definition of Quality
Throughout history, quality has been variously defined as “conformance to
requirements” [45], “best for the customer use and selling price” [46] and
“fitness for use” [28]. Juran has also referred to quality as “a distinguishing
feature of a grade or product (i.e., appearance, performance, length of life,
dependability, reliability, durability, maintainability, tastes, odor, etc.)” [47].
This definition is similar to what the software engineering discipline refers
to as non-functional characteristics of a software such as security, perfor-
mance, and reliability. In this respect, the ISO standard [27] defines quality
as “the totality of the characteristics of an entity that bear on its ability to
satisfy stated and implied needs”5. In business process modelling6, quality
is referred to a set of attributes that are related to a business process model
such as correctness, relevance, and clarity (see [48, 49, 50, 51]). These qual-
ity attributes are used to evaluate the quality of a business process model
not the business process itself which is the focus of this thesis.
In the context of this research, the term quality refers to distinguishing
features of a business process in the form of non-functional characteristics.
This definition is influenced heavily by Juran’s definition of quality [47] and
the ISO standard [27] definition of quality from the software engineering
discipline.
2.3.2 History of Quality Management
Quality has been a topic of research in many disciplines such as man-
ufacturing, software engineering, information management, and services
management. As a result, a variety of standards [52, 27, 53], frameworks
[54, 55, 56, 57] and quality management models [58, 59, 60, 28] have been
introduced to define, manage, assure, control and improve quality7.
The history of quality management in manufacturing dates back to the
1920’s, when Shewhart [58] introduced “Statistical Process Control” (SPC)
5 Refer to Sections 4.3 and 4.4.1.1 for further discussion on process quality vs product quality.6 The activity of creating a business process model which is the abstract description of abusiness process that represents selected process elements [4].
7 A quality model is “a strategy for commercial success that rests on the idea that businessessucceed to the degree that they satisfy their customers real requirements and continuouslyimprove in achieving this result.” (http://www.vitalentusa.com/learn/).
26 2
methods based on the continual monitoring of process variation and Control
Charts as a supporting tool. Shewhart’s quality management model consists
of three steps: (1) specifying what is needed; (2) producing products to sat-
isfy the specification; (3) and inspecting the products produced to see if
they satisfy the specification [61]. Ever since, SPC has been adopted by
other disciplines such as engineering, environmental science, and medicine
[62].
In 1930, Dodge and Romig introduced Acceptance Sampling Methods
Probabilistic (ASMP) which was another statistical quality control ap-
proach [59]. Their approach was based on predicting lot acceptability de-
rived from sampling results.
In 1950, Deming developed a statistical based approach to continuous
quality improvement which is referred to as “Deming’s PDCA Cycle” [60].
The cycle consists of a logical sequence of four repetitive steps for contin-
uous improvement: plan (plan ahead for a change, analyze and predict the
results), do (execute the plan in controlled circumstances), check (check the
result of the execution), and act (take action to improve the process).
Also in the 1950s, Juran [28] proposed a quality management model
known as the “quality trilogy” which was similar to Deming’s. Juran’s qual-
ity trilogy is based on three key steps of quality planning, quality controlling,
and quality improvement8. Juran’s philosophy was based on the fact that
the ability of an organisation to produce quality outcomes cannot happen
by accident; it must be planned for, and ongoing monitoring and control
need to take place. Firstly, to ensure the plan indeed occurs, and secondly,
to identify quality shortcomings during operations for further improvements.
Just-In-Time (JIT) is a Japanese management philosophy which has
been used in the manufacturing industry since the early 1970’s. It was first
developed within the Toyota manufacturing factory by Taiichi Ohno to meet
8 Quality planning is a preparation process that takes place to meet quality goals during pro-duction. Quality control is a process that takes place to ensure quality goals are met duringoperations (ensuring the operations are in accordance with the quality plan). Quality im-provement is the process that takes place for breaking through to unprecedented levels ofperformance.
2.3 Quality Management 27
consumer demands with minimum delays [63]. JIT follows a Lean manu-
facturing philosophy9 that provides capability for a manufacturing firm to
develop a strategy of continuous improvement in its competitive position
[64, 65]. JIT has its focus on process improvement by optimising value-
adding processes, and minimising or eliminating non-value-adding processes
that are wasteful [63, 66].
In 1980, Feigenbaum [46] introduced “Total Quality Control”. Feigen-
baum’s philosophy was based on two factors: (1) all functions in an organ-
isation need to be involved in the quality process, and (2) quality need to
be built into the product or service. He defines quality as “best for the
customer use and selling price”. His view on quality management is sum-
marized as “an effective system for integrating quality development, quality
maintenance and quality improvement efforts of the various groups within
an organisation, so as to enable production and service at the most econom-
ical levels that allow full customer satisfaction” [46].
Also in the 1980’s and early 1990’s, Total Quality Management (TQM)
started to be adopted by organisations. Joseph M. Juran10 and Philip B.
Crosby11 are known as the main contributors to this quality movement re-
ferred to as “Total Quality Management” (TQM) [67]. TQM provides a
framework for continuous improvement in an organisation [52]. Its primary
focus is on total satisfaction for both the internal and external customers.
It is about the prevention of defects and increasing the quality of design
[68]. The TQM philosophy is based on improving quality which leads to im-
proved productivity (decreased cost because of less rework, fewer mistakes,
fewer delays and better use of machines and materials). The word“Total”
means that everyone in the organization must be involved in the continuous
improvement effort, the word ”Quality” represents a concern for customer
satisfaction, and the word ”Management” refers to the people and processes
9 Lean is a manufacturing or management philosophy to reduce the lead time between a cus-tomer order and shipment of the ordered products or services through eliminations of allforms of waste [63].
10 Joseph Juran is an internationally acclaimed quality expert, who is well known on his contri-bution on Japanese manufacturing practices (www.mftrou.com/joseph-juran.html).
11 Philip B. Crosby was the founder and president of Philip Crosby Associations II -a quality consulting and training firm, known as ”Father of the Quality Revolution”(http://www.wppl.org/wphistory/PhilipCrosby/grant.htm).
28 2
needed to achieve the quality. TQM is defined in terms of five major compo-
nents: top management commitment, teams, culture, training, and process
efficiency [69]. “Top management commitment” refers to the ability and
vision of the leaders and management to control internal operations and
direct them toward accomplishment of quality goals and commitment to
continuous improvement. “Team” refers to the importance of teams and
group work on organizational performance in terms of increasing produc-
tivity, efficiency, and creativity. “Training and education” are crucial to
educate employees on the necessary elements of TQM. The TQM philoso-
phy requires permanent change in individual behaviors and attitudes that
contribute to the strengthening of an organisations culture. “Process effi-
ciency” promotes continuous improvement of all organisational operations.
The aim of enhancing “process efficiency” in an organisation is to identify
and correct the core problems that cause deficiencies.
In the 1980’s and 1990’s a number of other quality improvement ap-
proaches such as Kaizen, Six Sigma, and Lean Six Sigma (a summary of
each approach is described below) were introduced. These approaches are
very similar to JIT [63] in nature and share a common direction with em-
phasis on continuous improvement as a fundamental part of a quality model.
Kaizen is another Lean Japanese philosophy focusing on continuous im-
provement that involves everyone in an organisation. The word Kaizen
means “continuous improvement” [70]. Kaizen is a problem solving process
that supports process-oriented thinking [71, 72]. In Kaizen, improvements
are made by establishing standards. Quality control is achieved by following
these rules “(1) When an abnormality occurs, go to the gemba (where the
work is done) first (2) Check the gembutsu (!): machine, materials, rejects,
safety (3) Take temporary countermeasures immediately (4) Find the root
cause (5) Remove the root cause (6) Standardize, to prevent the trouble
from recurring” [70]. Kaizen represents the elements of continuous improve-
ment as a fundamental part of a quality model.
Six Sigma is a philosophy of conducting business with a focus on eliminat-
ing defects through reducing variations in company processes [73] - driving
2.3 Quality Management 29
towards achieving a process that does not produce more than 3.4 defects
per million opportunities. While it has been exploited as a quality improve-
ment framework by many top manufacturing organisations such as General
Electric (GE), Motorola, Honeywell, Bombardier, ABB, and Sony, it still
has limited use within service oriented companies [74]. In Six Sigma, de-
fects are avoided through the elimination of the causes of quality or process
related problems. It focuses on the number of opportunities within a process
that could result in defects rather than the quantity of the defects in a pro-
cess [75]. Six Sigma has been built based on previous quality management
models, such as Demings management philosophies and TQMs focus on the
customer [76]. Six Sigma is based on the DMAIC framework [77] which
consists of: (1) define - to define goals of improvement project and deliv-
erables for both internal and external customers (2) measure - to measure
the process to determine current performance (3) analyse - to anslyse and
determine the causes of the problem that needs improvement (4) improve -
to eliminate the defects and improve the process by eliminating defects (5)
control - to control future process performance. The primary objective of
the DMAIC process is “to recognize critical customer requirements, iden-
tify and validate the improvement opportunity, and upgrade the business
processes” [78].
Lean Six Sigma combines Lean management philosophy with Six Sigma
and shows how these two methodologies complement and reinforce each
other. Accordingly, Lean Six Sigma is “a methodology that maximizes share-
holder value by achieving the fastest rate of improvement in customer sat-
isfaction, cost, quality, process speed and invested capitals” [79].
A history of quality management in general was presented in this sub-
section. The next sub-section outlines a history of the quality management
in the business process area.
2.3.3 History of Quality Management in the Business Process
Area
Historically, within the business process community, quality has been ad-
dressed by the major practices such as Total Quality Management (TQM)
30 2
[18], Business Process Re-engineering (BPR) [19, 20, 14], and Business Pro-
cess Improvement (BPI) [21]12. Over time, each of these innovations have
incorporated some form of quality framework.
Sinclair and Zairi [12, 13] have introduced a total quality-based perfor-
mance measurement model13 for TQM which is based on a series of case
studies [22, 23, 24]. Their model integrates measurement within the over-
all management process, and consists of five levels: strategy development
& goal deployment, process management & measurement, performance ap-
praisal & management, break-point performance assessment, and reward &
recognition systems [24].
The Business Process Re-engineering initiative was proposed as a radi-
cal redesign of business processes to obtain dramatic improvements to cost,
time, quality and flexibility [19, 20, 14]. As a result, supporting methodolo-
gies for BPR, more or less, have incorporated support for managing quality.
The BPR view on using information technology as the enabler was another
significant development in the area which contributed to the IT governance
control frameworks such as COBIT14, which provides guidelines for the per-
formance of 34 identified IT processes within an organisation15.
Anupindi et al [9] refers to process quality as the ability of a process
to produce and deliver quality products. A distinction has also been made
between the internal and external quality of a business process [15]. An
emphasis on the controllable internal quality aspects of a business process
will ultimately determine the external quality perception of goods and ser-
vices created by the process [9]. This distinction is based on viewing the
quality of a business process from two points of view; resources working on
the process and clients who expect to receive goods and services created by
12 Refer to Section 2.2.2 for the history of the business process innovations.13 Total quality-based performance measurement has been defined as the measurement of non-
financial performance at different levels within the organization (levels such as individuals,teams, processes, departments and the organization as a whole), with an aim to the continuousimprovement of organisation performance [24].
14 COBIT is an IT governance framework that allows managers to bridge the gap between controlrequirements, technical issues and business risks. Visit this web site: http://www.isaca.org/,for further information on COBIT framework.
15 Refer to Figure 22 - page 25 in [80] for the complete list.
2.4 A Quality Management Model for BPM 31
the process. While both of these dimensions have been subject to dedicated
research, there is little general work on process quality, e.g. [81].
It has been acknowledged that quality management plays an important
role in the success of BPM. Zairi [43] has proposed a set of guidelines for
a successful BPM approach. In his view, business processes are critical ac-
tivities that deliver quality to the end customers. Accordingly, Zairi be-
lieves that management of processes should be conducted through perfor-
mance measurement in terms of quality. The outcome from the measurement
should be used to set targets for process improvement.
Contrary to the importance of quality management to BPM, there is
no structured framework to facilitate management of quality of business
processes during the different stages of the BPM life cycle.
2.3.4 Summary of Quality Management
In this section, a review of literature related to quality management was
presented. Working definitions were developed and examined. The focus of
the literature review was to (1) establish the context for describing and
elaborating the problem identified by reviewing the history of quality man-
agement in business process trends prior to BPM (such as BPI and BPR);
(2) to develop a quality management model that is suitable to be incorpo-
rated into the BPM life cycle [1] by examining existing quality management
models.
2.4 A Quality Management Model for BPM
Looking back at the history of quality management and quality models
introduced over the last few decades, it is clear that all these models share
a set of principles that, when applied, achieve quality goals. A summary of
these principles that have influenced the proposal of a quality management
model for BPM are listed below:
• Identifying quality requirements - Understanding the customer’s real re-
quirements and their quality needs is either directly or indirectly part
32 2
of most quality models presented above (Section 2.3.2). For example, in
Juran’s view [28], an important step of quality management is identifying
the quality needs of all the stakeholders involved in the process of pro-
ducing the product or service. Therefore, a quality management model
for BPM should support a stage in which the quality requirements for
business processes are identified.
• Planning for quality - This principle is an important part of the quality
management models introduced during early 1900’s, such as Statistical
Process Control (SPC) [58], Deming’s PDCA Cycle [60], and Juran’s
quality trilogy [28]. The most recent quality models such as Six Sigma
(DMAIC framework) [77] have more emphasis on quality improvement
and, as such, do not provide supporting frameworks for quality planning
and implementation. Therefore, a quality management model for BPM
should support a stage in which the implementation of identified quality
requirements are planned.
• Controlling quality - Quality can be controlled by both eliminating de-
fects and reducing the lead time between customer order and shipment
through elimination of all forms of waste. Acceptance Sampling Methods
Probabilistic [59] and Six Sigma are examples of quality models support-
ing quality control via defect elimination. Just-In-Time, Kaisen, Lean
Six Sigma are examples of quality models supporting quality control by
reducing the lead time between customer order and shipment of the or-
dered products or services. Therefore, a quality management model for
BPM should support a stage in which the quality of business processes
are controlled.
• Continuous improvement - Continuous improvement has been a principle
of most of the quality management models listed in the previous section,
specifically those introduced during and after 1950. Therefore, a quality
management model for BPM should support a stage in which the quality
of business processes are continuously monitored for improvement.
2.4 A Quality Management Model for BPM 33
Quality Definition
Quality Control
Quality Improvement
Quality Implementation
Fig. 2.3. BPM Quality Management Model
Based on the above principles, this thesis proposes a quality manage-
ment model for BPM that consists of four key phases of quality definition,
quality implementation, quality control and quality improvement16.
Figure 2.3 depicts the proposed quality management model. As shown in
Figure 2.3, these four key phases are arranged in a cyclical structure. This
quality management model is an extension of Juran’s quality management
model in which the quality planning phase is replaced with two distinct
phases: quality definition, and quality implementation. The following para-
graphs briefly introduce each phase.
Quality definition - The main purpose of the quality definition phase
is to identify the quality requirements of a business process.
Quality implementation - The main purpose of the quality imple-
mentation phase is to implement the identified quality requirements of a
business process model.
Quality control - The main purpose of the quality control phase is to
ensure that the quality requirements of the business process are met during
the enactment of the process.
16 Refer to Section 4.2 for further details on how this quality management model is integratedinto the BPM life cycle.
34 2
Quality improvement - The main purpose of the quality improvement
phase is to improve the quality of a business process. During this phase,
the quality of the enacted business process is evaluated against the original
quality requirements in order to identify the improvement opportunities.
2.5 Chapter Summary
This chapter presented a review of literature related to business processes
management and quality management. Working definitions were also devel-
oped. The focus of the literature review was firstly, to establish the context
of the research presented in this research; secondly, to provide a context for
describing and elaborating the problem being identified; and thirdly, to de-
velop a quality management model for BPM by examining existing quality
management models.
As discussed, none of the quality management frameworks reviewed and
presented in Section 2.3 supports all the four key principles that, when
applied, achieve quality goals. The quality management model proposed in
Section 2.4 consists of four key phases: quality definition, quality implemen-
tation, quality control and quality improvement.
3
Research Approach and Methodology
3.1 Introduction
The purpose of this chapter is to describe the research approach undertaken
in conducting this research study1. The value of combining research meth-
ods in Information Systems (IS) research has received significant acclaim
[83, 84]. Mingers [84] argues that “different research methods (especially
from different paradigms) focus on different aspects of reality and therefore
a richer understanding of a research topic will be gained by combining sev-
eral methods together in a single piece of research or research program”. A
multi-method research design utilising the design science approach and ac-
tion research methodology was chosen for this study with the aim to “deliver
practical value to the subject while at the same time contributing to theory”
[31]. Section 3.2 describes in detail the reasons for adopting a multi-method
research design for this study. A brief description on the design science ap-
proach is provided in Section 3.3. Action research methodology is described
in Section 3.4. The multi-method research design for this study is described
in detail in Section 3.5.
3.2 Research Approach and Methodology Selection
Most of the research in the Information Systems (IS) discipline2 are char-
acterised by two paradigms: design science and behaviourial science [2].
1 Research is an activity that contributes to understanding of a phenomenon which is a set ofbehaviours of an entity that is found interesting by the researcher [82].
2 IS research is the study of phenomenons related to Information Systems (IS). Organisationsimplement Information Systems to improve the effectiveness and efficiency throughout theirorganisations [2].
36 3
Design-science is a research paradigm that extends the boundaries of hu-
man and organisational capabilities by creating new and innovative artifacts
[2]. The behavioural science paradigm “seeks to develop and justify theories
(i.e., principles and laws) that explain or predict organizational and human
phenomena surrounding the analysis, design, implementation, management,
and use of information systems” [2]. According to March et al. [85], a be-
havioural science paradigm is selected as a research approach if the research
relates to the understanding of the nature of IS; alternatively, a design sci-
ence paradigm is selected as a research approach if the research relates to
the improvement of IS performance.
Once the research questions3 that drove this study were defined, it be-
came apparent that a design science paradigm is a suitable research ap-
proach for this study as addressing the research questions will be a contri-
bution to IS research by improving IS performance.
Design-science is a research paradigm that extends the boundaries of
human and organisational capabilities by creating new and innovative ar-
tifacts. Employing a design science approach on its own is not encouraged
in the IS discipline, as Hevner et al. [2] suggests “A justified theory that is
not useful for the environment contributes as little to the IS literature as
an artifact that solves a nonexistent problem”. For that reason, Hevner et
al. have proposed an IS research framework which is based on combining
behavioural science and design science paradigms. Figure 3.1 presents the IS
research framework proposed by [2]. In this framework, the environment de-
fines the problem space in IS research which includes people, organisations
and technology. The research problem perceived by the researcher (derived
from business needs) transpires from the environment. The business needs
are influenced by people and are assessed and evaluated within the context
of an organisation (organisational strategies, structure, culture, and existing
business processes). Accordingly these needs are shaped with relation to the
existing technology.
3 Refer to Section 1.1.2.
3.2 37
Fig. 3.1. Information Systems Research Framework as defined by Hevner et al. [2]
Having identified the business needs, IS research is conducted in two
complementary phases - design science (develop/build) and behaviourial
science (justify/evaluate). During the design science phase, the researcher
addresses the research through the building of artifacts designed to meet the
identified business needs. The applicability of the designed artifacts to the
business needs are then evaluated during the behaviorial science phase. The
knowledge base provides foundations (theories, frameworks, instruments,
constructs, models, methods, and instantiations) and methodologies (data
analysis techniques, formalisms, measures, and validation criteria) that have
resulted from prior research studies. Foundations are used during the design
phase, while methodologies are used for evaluation during the behaviorial
science phase. Based on this framework, the contributions of design science
and behaviourial science in IS research are assessed by (1) applying to the
business needs in an appropriate environment, and (2) the value added to
further research and practice as the result of adding to the contents of the
knowledge base [2].
38 3
The research design for this study is influenced by the IS framework pro-
posed by Hevner et al. as it is based on both behavioural science and design
science paradigms. The research design for this study utilises the design
science paradigm as a research approach to innovate new artifacts, and the
action research paradigm as a methodology to evaluate the applicability of
the designed artifacts to real world business needs. Action research is se-
lected as a methodology for the evaluation phase as it provides a potential
avenue to improve the practical relevance of information systems research
[86]. Combining a design-based research approach with an action research
methodology is a useful way to create business knowledge that is both rel-
evant (for both practice and theory) and rigorous [32].
3.3 Design Science Paradigm
The design science paradigm is a problem-solving paradigm [2] which aims
to provide answers to design problems [32]. The design science method-
ology, in general, consists of a process (set of activities) and a product
(artifact) [2, 87, 88]. It means the design process is a sequence of activities
that produces an innovative artifact. The design science methodology by
[88] identifies two design processes: build and evaluate; and four artifacts:
constructs (vocabulary and symbols), models (abstractions and representa-
tions), methods (algorithms and practices), and instantiations (implemented
and prototype systems). Constructs are the conceptual vocabulary in which
problems and solutions are defined. A model is a set of propositions that
presents the relationship between constructs. A method is a set of proce-
dures used to perform a task. Instantiations are operationalised constructs,
models, and methods - an instantiation is the realisation of the artifact in
an environment [88].
3.4 Action Research Paradigm
Action research is a research approach introduced by Kurt Lewin in 1946 to
address social system change through action by means of effecting change
3.4 39
and creating knowledge about the change [89]. Action research aims at pro-
viding solutions for current practical problems while expanding scientific
knowledge [86]; therefore, a balance between the goal of the researcher and
the participating sponsor must be maintained. It is a form of applied re-
search that adds value to the practice by solving a practical problem, while
at the same time contributes to a research community by developing the-
oretical knowledge [31, 90]. Action research is suited in social situations in
which the researcher must be engaged. Cole et al. [89] have defined a set of
conditions for an ideal action research social setting. These conditions in-
clude: (a) the researcher must be actively involved, with explicit benefit for
both researcher and organisation; (b)the knowledge obtained can be imme-
diately applied; and, (c) the research is a cyclical process that links theory to
practice. Action research provides an opportunity for the researcher to be-
come involved in practical problem solving through the close collaboration
with practitioners from participating orgainsations.
Diagnosis
Action Planning
Action TakingEvaluating
Specifying Learning
Fig. 3.2. The Action Research Cycle [3]
A number of action research methods have been developed [91], one of
the best known being Susman and Evered’s action research cycle [3] consist-
ing of five phases. Figure 3.2 depicts the action research cycle by Susman
and Evered [3]. The purpose of the first phase, diagnosis, is to identify and
40 3
define a problem. The second phase, action planning, involves defining ac-
tions that need to be taken to solve the problem. The third phase, action
taking, consists of executing the planned actions. The fourth phase, evalu-
ating, is aimed at studying the consequence of the action. The fifth phase,
specifying learning, completes the loop by identifying lessons learned.
This study adopts Susman and Everet’s action research approach as it fits
the purpose of evaluating solution concepts, specifically its cyclical aspect.
3.5 Research Design - Multi-Method Approach
The purpose of this section is to present how two research methods (design
science and action research) are combined and how the use of a multi-
method approach supports the identification and development of several
contributions within this thesis. The justification for using a multi-method
research design was presented in Section 3.2. The research design for this
study is influenced by two frameworks:
• The IS research framework by [2] - This framework is based on combin-
ing design science (develop / build) and behaviourial science (justify /
evaluate) paradigms (see Figure 3.1). The IS research framework by [2]
was described in Section 3.2.
• The design-based research framework by [32] - This framework con-
tributes to theory and practice via two distinctive but interconnected
streams: design science and action research. The design-based research
stream uses the reflective cycle4, and its objective is to develop knowledge
that contributes to theory by creating desired situations. The action re-
search stream is based on action research using the problem solving cycle,
and its objective is to contribute to the practical concerns in problematic
situations by solving particular problems.
Figure 3.3 depicts the multi-method approach adopted in this research
which is based on both the IS research framework [2] and the design-based
4 The aim of a reflective cycle is to reflect on the results of the action research stream, reviewingthe lessons learned and to identify the areas in which the solution can be improved possiblythrough the redesign.
3.5 Research Design - Multi-Method Approach 41
Case n
2. Agenda Setting
Action Taking
Design Science Methodology
Action Research Methodology
Research Problem
1. Theorising
Conceptual Framework
3. (Re) Designing
Solution Concept
9. Reflecting
Success & Improvements
10. Developing Knowledge
Design Knowledge
Case 2
Case 1
4. Diagnosing
Practice Problem
5. Action Panning
Specific Solution
6. Action Taking
Record of the evolving process
7. Evaluating
Consequences of actions
8. Specifying Learning
FindingsClient Agenda
Mat
ch ?
Fig. 3.3. Research methodology of a design-based research study using action research
research approach by [32]. As shown in Figure 3.3, this research is based on
two streams: design science and action research. The objective of the design
science stream is to design and build artifacts as solutions to the research
problem. The action research stream evaluates the artifacts in practice for
its distinct feature of “delivery of research findings that are immediately
applied to practice” [86]. The action research stream is based on the action
research proposed by Susman and Everet [3]. The steps in this multi-method
approach are described later in this section.
The high level research design used in this study is depicted in Fig-
ure 3.4. This diagram presents activities related to the different stages of
this research based on the multi-method methodology described above (see
Figure 3.3). Ten horizontal lanes present ten stages of the multi-method
research. The diagram is divided into two sections, all the activities (rep-
resented by rectangles) related to design science are presented on the left
hand side, while action research related activities are presented on the right
hand side of the diagram. The action research side of the diagram is divided
by dotted lines to represent the three action research cases: Organisation
A, Organisation B, and Organisation C.
42 3E
valu
atin
g
(AR
)
Eva
luat
ing
(A
R)
Dia
gn
osi
ng
(A
R)
Dia
gn
osi
ng
(A
R)
Act
ion
P
lan
nin
g (
AR
)
Act
ion
P
lan
nin
g (
AR
)A
ctio
n T
akin
g
(AR
)
Act
ion
Tak
ing
(A
R)
Sp
ecif
yin
g
Lea
rnin
g (
AR
)
Sp
ecif
yin
g
Lea
rnin
g (
AR
)A
gen
da
Set
tin
g (
DS
)
Ag
end
a S
etti
ng
(D
S)
(Re)
D
esig
nin
g
(DS
)
(Re)
D
esig
nin
g
(DS
)R
efle
ctin
gR
efle
ctin
gD
evel
op
ing
K
no
wle
dg
e
Dev
elo
pin
g
Kn
ow
led
ge
Th
eori
sin
g
(DS
)
Th
eori
sin
g
(DS
)
Literature ReviewDevelop Quality-Aware BPM Life
Cycle
Define Research Problem
Define Research Questions
Build Quality of Business Process (QoBP) framework
Develop Quality Management
Model for BPM
Build Business Process Root
Cause Analysis (PRCA) technique
Identify the problem
Identify the problem
Identify the problem
Define actions need to be taken
Define actions need to be taken
Define actions need to be taken
Execute the planned action
Execute the planned action
Evaluate the consequence of
Action
Evaluate the consequence of
Action
Evaluate the consequence of
Action
Identify lesson learned
Identify lesson learned
Identify lesson learned
Refine QoBP framework
Refine QoBP framework &
PRCA technique
Refine QoBP framework
Execute the planned action
Reflect on Organisation A lessons learned
Reflect on Organisation C lessons learned
Reflect on Organisation B lessons learned
Publish the solution
Organisation A Organisation COrganisation B
Design Science Action Research
Fig. 3.4. Research Design
Note: The first three stages listed below belong to the design science part
of this multi-method methodology (the top box in figure 3.3).
Stage One, Theorising - The first stage, is the inception phase of the
research when the theory of developing a conceptual framework about “qual-
ity management of business processes during their life cycle” is employed.
The main purpose of this phase is to review prior and relevant literature
in order to create a firm foundation for advancing knowledge by facilitating
theory development [33] - uncovering areas where research is required. Ac-
cordingly, this stage starts with the review of the relevant literature to 1)
3.5 Research Design - Multi-Method Approach 43
establish the context of the research presented in this thesis; 2) provide a
context for describing and elaborating the problem being identified; and 3)
develop a quality management model for business processes by examining
existing quality management models. Upon completion of the preliminary
literature review, a foundation for proposing a conceptual model for the
quality-aware BPM life cycle5 is employed. Chapter 2 presents a summary
of the reviewed literature and the proposed quality model for business pro-
cesses which is the outcome of this stage.
Stage Two, Agenda Setting - During this stage, the research ques-
tions that need to be addressed to provide a solution for the identified
research problem are articulated. Section 1.1.2 describes the research prob-
lem and research questions identified during this stage.
Stage Three, (Re) Designing - This is the stage in which the artifacts
are designed and developed to address the research questions identified in
the previous stage. Three main artifacts that are built during this stage
are the quality-aware BPM life cycle5, Quality of Business Process (QoBP)
framework 6, and Process Root Cause Analysis (PRCA) technique7.
Note: the next five stages listed below belong to the action research part of
this multi-method methodology which are based on the five stages of action
research methodology proposed by [3]. These stages are aimed at evaluating
the artifacts designed during the last stage in practice8. A more detailed
protocol for conducting action research as part of this study is presented
in Section5. As shown in figure 3.4, three cycles of action research will be
conducted within three organisations ( organisation A, organisation B, and
organisation C) in this research. Multiple action research cycles enables a
progressive refinement of the developed artifacts [32]. A detailed report on
each action research cycle will be presented in this thesis9.
5 Refer to Section 4.2 for further details on the Quality-aware BPM life cycle.6 Refer to Sections 4.3, and 4.4 for further details on the QoBP framework.7 Refer to Section 4.5 for further details on PRCA technique.8 Rigor and relevance of each action research case is discussed in the chapter related to eachcase.
9 Chapters 6, 7, and 8 present a detailed report on the action research cycles.
44 3
Stage Four, Diagnosing - During this stage, a practical problem that
is similar to the research problem is identified. Section 5.3.2 provides the
protocol for this stage of the action research cycle.
Stage Five, Action Planning - During this stage, the activities that
are performed during the course of the collaboration, to solve the identified
problem, are planned. Section 5.3.3 provides the protocol for this stage of
the action research cycle.
Stage Six, Action Taking - During this stage, the actions planned in
the previous step are performed. Section 5.3.4 provides the protocol for this
stage of the action research cycle.
Stage Seven, Evaluating - During this stage, the consequences of the
actions taken in the previous stage are evaluated. Section 5.3.5 provides the
protocol for this stage of the action research cycle.
Stage Eight, Specifying Learning - During this stage, the lessons
learned from the action research cycle are identified in order to determine
the areas in which the solution can possibly be improved through redesign.
Section 5.3.6 provides the protocol for this stage of the action research cycle.
Stage Nine, Reflecting - During this stage, the lessons learned from
each action research cycle are analysed and reflected. As shown in Figure 3.4,
the last six stages (from stage three to stage nine) are repeated three times
in an evolutionary manner with each action research case providing an op-
portunity to mature the conceptual framework for the purpose of attaining
theoretical saturation [92].
Stage Ten, Developing knowledge - Finally, during the last stage,
the solution is formalised in the form of this thesis to contribute to the
knowledge base.
The following section presents the relationship of this research to the
Information Systems (IS) research guidelines.
3.6 Relation to IS Research Guidelines 45
3.6 Relation to IS Research Guidelines
The purpose of this section is to describe how the contribution from this
thesis will be evaluated in relation to the Information Systems (IS) research
guidelines provided by [2]. Hevner et al. recommend seven guidelines for
effective information systems research, specifically those with the design
science focus. These guidelines are briefly outlined below.
Guideline 1: Design as an Artifact Information research should pro-
duce a viable artifact in the form of a construct, a model, a method, or an
instantiation.
Guideline 2: Problem Relevance The design-science research should
develop IS based solutions to important and relevant business problems.
Accordingly, the research must design effective artifacts (constructs, mod-
els, methods or instantiations) that address the relevant business problems.
Guideline 3: Design Evaluation The utility, quality, and efficiency
of a design artifact must be rigorously evaluated via effective evaluation
methods.
Guideline 4: Research Contributions The design-science research
must contribute to the knowledge base in the areas of the design artifact,
design foundations, and/or design methodologies.
Guideline 5: Research Rigor The construction and evaluation of the
design artifact must be based on the application of rigorous methods using
the knowledge base and its methodologies and foundations.
Guideline 6: Design as a Search Process Design is a search pro-
cess that discovers an effective solution to a problem [2]. The design science
research consists of several crucial components which are abstraction and
representation of appropriate means, ends, and laws. Means in this con-
text are the set of actions and resources available to build a solution, ends
represent goals and constraints, and laws are uncontrollable forces in the
environment. This implies that “the set of possible design solutions for any
46 3
problem is specified as all possible means that satisfy all end conditions
consistent with identified laws”.
Guideline 7: Communication of Research Design-science research
must be presented effectively both to the academic community (technology-
oriented audiences) and practitioners (management-oriented audiences).
The research should communicate the benefits offered by the artifacts, as
well as the cumulative knowledge base built as the result of the research.
The cumulative knowledge bases can then be further extended and evalu-
ated by other researchers and practitioners.
Section 9.3.1 provides a detailed discussion on how well this thesis meets
these guidelines that were outlined above.
3.7 Chapter Summary
This chapter provided a detailed discussion of the research approach and
methodology followed in this research. The multi-method methodology
adopted for this research, which is based on design research approach and
action research evaluation, was outlined in this chapter. This chapter also
outlined seven recommended IS research guidelines which will be used later
in this thesis to justify how well this research suffices international research
standards in the IS discipline.
Part II
Design Science Phase
4
The Design Science Phase
4.1 Introduction
This is the main chapter of Part 2 of this thesis which is dedicated to the
design science phase1. The main purpose of this chapter is to present the
artifacts being developed during the design phase of this research. As out-
lined in Section 1.1.2, the core research problem that generated this study
is: How can organisations manage the quality of the business processes dur-
ing different phases of the BPM life cycle?. Figure 4.1 presents an outline of
the artifacts presented in this chapter in relation to the research questions
being addressed.
Section 4.2 presents the first artifact - quality-aware business process
life cycle - which is developed to address the main research question: “How
can quality be incorporated into a business process and managed during the
BPM life cycle? ”. This section briefly revisits the justification for incorpo-
rating a quality management framework into the BPM life cycle, followed
by a detailed description of the proposed quality-aware business process life
cycle.
In the quality-aware BPM life cycle, the quality of a business process is
managed based on the four key phases of: quality definition, quality imple-
mentation, quality control, and quality improvement. The proposed quality-
aware BPM life cycle is the outcome of the investigation conducted during
the early stage of this study to define the research questions and the scope
of this study in a structured manner.
1 Refer to Section 3.5 for further details on this thesis research strategy.
50 4 The Design Science Phase
Research Question Proposed Artifact (s)
Section 4.2How can quality be incorporated into a business process and managed during the BPM life cycle?
Quality Aware BPM Life Cycle
Section 4.3 What are the business process quality dimensions? QoBP Framework - Quality Model
Section 4.4How can quality be incorporated into a business process model producing a quality-aware business process?
QoBP Framework - Softgoal Model QoBP Framework - Softgoal Correlation Model QoBP Framework - Measurement Model QoBP Framework - QoBP Metamodel QoBP Framework - QoBP Methodology
Section 4.5What is a suitable root cause analysis technique for identifying the root causes of the quality issues of a business process?
PRCA Technique
Fig. 4.1. Research Questions & Proposed Artifacts
The scope2 of this research is limited to providing supporting artifacts
for the first and last phases of the quality-aware BPM life cycle: quality
definition and quality improvement. The research questions derived in Sec-
tion 1.1.2 are related to the quality definition and the quality improvement
phases of the quality-aware BPM life cycle. Sections 4.3, 4.4, and 4.5 present
the artifacts developed to address the research questions defined in Sec-
tion 1.1.2.
Section 4.3 introduces the Quality of Business Process (QoBP)
framework in which the Quality Model proposed in Section 4.3 is utilised
to create a quality-aware business process model. The quality model is the
first artifact developed to support the quality definition phase. The main
purpose of the quality definition phase is to define and model the quality
requirements of a business process during the analysis and design phases of
the BPM life cycle. The quality model provides a structured approach to
capture and represent the quality requirements of a business process. The
quality model addresses the first research question related to the quality
2 Refer to Section 1.1.1.
4.2 Quality-aware BPM Life Cycle 51
definition phase: “what are the business process quality dimensions?”.
Section 4.4 presents the additional artifacts of the QoBP framework de-
veloped by this thesis to support the quality definition phase of the quality-
aware BPM life cycle. These artifacts are developed to address the second
research question related to the quality definition phase: “how can quality be
incorporated into a business process model producing a quality-aware busi-
ness process?”. This section presents how in the Quality of Business Process
(QoBP) framework, the quality model, proposed in Section 4.3, is utilised
to create a quality-aware business process model.
Section 4.5 presents the artifact that is developed to support the quality
improvement phase of the quality-aware BPM life cycle. This artifact is
developed to address the fourth research question that is related to the
quality improvement phase of the quality-aware BPM life cycle: “what is
a suitable technique for identifying the root causes of the quality issues of
a business process?”. This section introduces a novel root cause analysis
approach that is referred to as Process Root Cause Analysis (PRCA)
Technique.
4.2 Quality-aware BPM Life Cycle
This section presents the first artifact (Quality-aware BPM Life Cycle)
that is developed to address the main research question: “How can quality
be incorporated into a business process and managed during the BPM life
cycle?”. This section presents how a quality management model is inte-
grated into the BPM life cycle.
The justification for incorporating quality into BPM and business pro-
cesses was presented in Section 1 and 2.3.3. Section 1 discussed how quality
has been an important topic within the business process community as it has
been addressed by most of the practices in the area such as Six Sigma [17],
Total Quality Management (TQM) [18], Business Process Re-engineering
(BPR) [19, 20, 14], and Business Process Improvement (BPI) [21]3. Section
3 Refer to the sections 2.2.2, and 2.3.3 for the further details on the history of the businessprocess innovations.
52 4 The Design Science Phase
2.3.3 outlined the guidelines for a successful BPM approach. It was also
discussed how the management of processes should be conducted through
performance measurement in terms of quality, and how the measurement
outcome should be used to set targets for process improvement. Improving
the quality of a process may jeopardise other process performance metrics
such as cost, time and flexibility. These four process performance indicators
(quality, cost, time and flexibility) are referred to as the devils quadrangle
[93]. It’s called devils quadrangle, because in general, improving upon one
dimension may have a weakening effect on another [93]. It is therefore es-
sential to be aware of the trades-offs that need to be made, as an exclusive
quality focus may compromise other performance indicators such as time,
cost and flexibility. The cost trade-offs and measures such as “return on
quality”, in general, have been the topics of interest during the past two
decades leading to the proposal of several trade-offs models [94, 95, 11].
The anecdotal and empirical evidence suggests that over time, improving
quality reduces the overall costs [96, 11].
Contrary to the importance of quality management to BPM, to our
knowledge there is no structured framework to facilitate management of
quality of business processes during the different stages of the BPM life
cycle. This chapter presents the quality-aware BPM life cycle in which our
proposed quality management model is incorporated into the BPM life cycle.
The proposed quality-aware BPM life cycle is the outcome of the investi-
gation conducted during early stages of this study to define the research
questions and the scope in a structured approach. As described in Section
1.1.1, the scope of this research is limited to provide supporting artifacts
for the first and last phases of the quality-aware BPM life cycle: quality
definition and quality improvement.
In the quality-aware BPM life cycle (Figure 4.2), the quality of a business
process is managed based on the four key phases of quality definition, quality
implementation, quality control, and quality improvement. Figure 4.2 shows
this is a cyclical life cycle where the quality improvement opportunities
identified during the quality improvement phase are fed to the quality defi-
nition phase, commencing a new cycle instance. Sections 4.3 to 4.5 present
4.2 Quality-aware BPM Life Cycle 53
Analysis
Design
Implementation
Enactment
Monitoring
Evaluation
Business Process Requirements & Quality Requirements
Quality Aware Business Process Model
Implemented Quality Aware ProcessProcess & Quality Metrics
Measures for Improvements
Measurements
Process & Quality Metrics
Quality Improvement
Quality Definition
Quality Implementation
Quality Control
Fig. 4.2. Quality-aware Business Process Management Life Cycle
the artifacts developed to address these research questions.
The description of this model which is based on the quality manage-
ment phases (quality definition, quality implementation, quality control,
and quality improvement) are presented below.
Quality Definition
The purpose of the quality definition phase is to define the quality require-
ments of a business process, therefore, this phase is incorporated into the
analysis and design phases of the BPM life cycle (as shown in Figure 4.2).
The quality-aware BPM life cycle begins with the analysis phase which is
concerned with the analysis of the organisational structure, process goals,
the process environment, and process quality requirements. When analysing
the process goals, and the process quality requirements it is important to en-
sure that they are aligned with organisation’s strategy4. During this phase,
the functional and quality (non-functional) requirements5 of a business pro-
cess are elicited, taking account of the organisations’ strategy, goals and
4 Refer to Section 2.2.3 for further details on the analysis and design phases of the BPM lifecycle.
5 The functional requirements at this level contain a high level description of the activitiesof the process being analysed (e.g. “upon receive of the loan application, evaluate the ap-plication to determine either the loan can be approved or needs to be rejected”). Quality(non-functional) requirements include quality related details of the process being analysed(e.g. the loan approval should be performed within an acceptable response time).
54 4 The Design Science Phase
structure. The output from this phase includes the functional and quality
(non-functional) requirements description of the business process. In the
design phase, the overall process structure is then engineered based on the
requirements from the analysis phase. The design includes the identifica-
tion of the activities of a process; specification of human resources involved
with the activities and their role within the organisation; specification of
non-human resources (such as computer systems, printers, projectors etc)
required; and specification of data & information associated with the activ-
ities. After identifying all the functional dimensions of the business process
(activities, human resources, non-human resources, and inputs & outputs),
quality aspects are identified for these functional dimensions. During this
phase the business process is modeled using a business process modeling
notation. The quality requirements related to all the dimensions of a busi-
ness process are incorporated into the business process model producing a
quality-aware business process model. Quality-aware business process
models are the main deliverable artefact of the design phase.
Quality Implementation
The purpose of the quality implementation phase is to implement a quality-
aware business process model. As shown in Figure 4.2, quality implementa-
tion is incorporated into the implementation phase of the BPM life cycle.
During this phase, the infrastructure to support the quality-aware business
process is designed and established. All the quality requirement identified
in the design phase are implemented during this phase.
Quality Control
The purpose of the quality control phase is to ensure that the quality re-
quirements of the business process are met during each enactment of the
process. Therefore quality control is incorporated into the BPM life cycle at
the time that a business process is enacted and monitored (see Figure 4.2).
During this phase individual instances are executed using the dedicated in-
frastructure. Monitoring is an administrative phase which is bound to each
individual process instance. The main purpose of this activity is to visualise
the status of business process instances by providing insight to the process
instance. The information related to the quality aspects of the process are
4.2 Quality-aware BPM Life Cycle 55
monitored and measured for each individual process instance during this
phase.
Quality Improvement
The purpose of the quality improvement phase is to improve the quality
of a business process. Therefore, the quality improvement is incorporated
into the evaluation phase of the BPM life cycle where quality of the enacted
business process is evaluated (as shown in Figure 4.2). The quality improve-
ment at this stage of the business process life cycle is concerned with the
root cause analysis (RCA) of the cases where quality requirements were not
met. These cases are referred to as quality issues. In this context root cause
analysis is used as a reactive approach to uncover the root causes of the
quality issues that have already occurred. Identification of the root causes
of the quality issues will be used to improve the subsequent enactments of
the business process6.
The scope of this thesis is limited to providing supporting artifacts (such
as frameworks, models, and methodology) for the quality definition and
quality improvement phases of the quality-aware BPM life cycle.
This section presented how the proposed quality management model (in-
troduced in Section 2.3.4) is incorporated into the BPM life cycle producing
a quality-aware BPM life cycle. The purpose of the quality-aware BPM life
cycle is to incorporate quality in terms of quality characteristics into a
business process model that can be implemented, enacted, and constantly
monitored and evaluated for further improvement.
The next section introduces the first artifact of the Quality of Busi-
ness Process (QoBP) framework developed to support the quality definition
phase of the quality-aware BPM life cycle.
6 Refer to Section 4.5 for further information on Process Root Cause Analysis framework.
56 4 The Design Science Phase
4.3 Quality Definition Phase - QoBP Framework Part
I
This section introduces the first artifact of the Quality of Business Pro-
cess (QoBP) framework. The first artifact, the quality model is devel-
oped to support the quality definition phase of the quality-aware BPM life
cycle (highlighted orange in Figure 4.3). As shown in Figure 4.3, in the
quality-aware BPM life cycle, the quality of a business process is managed
based on the four key phases of: quality definition, quality implementation,
quality control, and quality improvement. The main purpose of the quality
definition phase is to define and model the quality requirements of a busi-
ness process during the analysis and design phases of the BPM life cycle.
As described in Section 4.2, during the analysis phase the functional and
quality (non-functional) requirements of a business process are elicited, tak-
ing account of the organisation’s strategy, goals and structure. The output
from this phase includes the functional and quality (non-functional) require-
ments of the business process. During the design phase, the overall process
structure is engineered based on the requirements from the analysis phase
- incorporating the quality requirements into the business process model,
producing a quality-aware business process model. This Section presents
the first artifact developed by this thesis to support the quality definition
during the design phase. The quality model provides a structured approach
to capture and represent the quality requirements of a business process.
As stated in Section 2.3.1, in the context of this research, the term qual-
ity refers to the non-functional characteristics of a business process. As
discussed in Section 1, the enactment of a business process is functionally
correct (all the events and functions are enacted in the order they have been
defined), but the outcome is nevertheless unacceptable because the outcome
does not meet some quality criteria such as timeliness and accuracy. For ex-
ample, in a hypothetical mortgage scenario, while the loan approval process
for a customer is completed functionally correct, the outcome may not be
successful for the bank as the customer may decide to take the loan from an-
other bank as the process took longer than the originally promised time line.
4.3 Quality Definition Phase - QoBP Framework Part I 57
Analysis
Design
Implementation
Enactment
Monitoring
Evaluation
Business Process Requirements & Quality Requirements
Quality Aware Process Model
Implemented Quality Aware ProcessProcess & Quality Metrics
Measures for Improvements
Measurements
Process & Quality Metrics
Quality Improvement
Quality Definition
Quality Implementation
Quality Control
Fig. 4.3. Quality Definition Phase
The quality characteristics of a business process are more difficult to
capture and as a result they are either overlooked or deferred [16]. It would
be beneficial to have a structured model to capture and represent quality
characteristics of a business process. Quality has been well defined in the
Software Engineering and Service Management areas in the form of quality
characteristics (see Sections 4.3.1.1 and 4.3.1.2) categorised into meaningful
groups. Several literatures have indirectly and directly identified the lack
of existing business process modelling methods for the elicitation and mod-
elling of non-functional requirements of a business process, but these works
have not been able to provide a structured model to capture and represent
the quality characteristics of a business process.
Heravizadeh et al. [97] proposed the concept of context-aware business
process in order to support knowledge-intensive processes. The authors
categorised contextual information into three groups: resource-oriented,
method-oriented, and environment-oriented. Resource-oriented contextual
information is concerned with whatever resource or resources are involved
in performing a given function (e.g. the experience level of a user). Method-
oriented contextual information is concerned with the way a function is
executed, and the time taken for that execution. Environment-oriented con-
textual information describes the conditions in which a process is enacted,
58 4 The Design Science Phase
such as the location or locations at which the process was enacted, the date
or dates involved, and the time of the day. Rosemann et al. [98] have also
proposed the concept of context-aware process design in order to increase
the adaptability of process modeling. Such context-aware information, in-
directly, necessitates the non-functional requirements of a business process.
Pavlovski et al. [16] define non-functional characteristics of a business
process as operational behavior and the associated process constraints. Ac-
cordingly they propose operating conditions to denote a business process
constraints and control cases to define controlling criteria to minimise the
risk associated with an operational condition. While these artifacts (oper-
ating condition and control case) can capture operational constraints, no
empirical studies have yet been performed to provide evidence of the effi-
ciency of these artifacts). Operating condition and control case are not ca-
pable of capturing and representing other non-functional characteristics of a
business process (non-operational constraints). Aburub et al. [99] have also
proposed a business process improvement approach which is based on the
non-functional requirements of the business process. In their approach they
improve a business process by analysing the non-functional requirements
of a business process and altering the process to meet these requirements.
Their approach has not been empirically evaluated and no structured model
or framework is provided to capture and represent the quality characteris-
tics.
In this research, a quality model is proposed to address the shortcoming
of the earlier works by providing a well structured model to capture and
represent quality (non-functional) characteristics of a business process. It is
acknowledged that quality of a business process builds on the quality of its
functions. In essence there are two levels of granularity at which the quality
of functions can be analysed: for the function as a whole, or by looking
into the entities related to it. Accordingly, in this thesis, the proposed qual-
ity model models the quality of a business process (see Figure 4.4) based
on four distinct dimensions: quality of functions (Section 4.3.2.1), quality
of input and output objects (Section 4.3.2.2), quality of human resources
(Section 4.3.2.3), and quality of non-human resources (Section 4.3.2.4). The
4.3 Quality Definition Phase - QoBP Framework Part I 59
quality model addresses the shortcoming of the earlier works by introducing
a model that defines the quality of a business process based on its four di-
mensions. This model also provides a set of quality characteristics for these
four dimensions derived from related domains. The quality model provides
a structured approach to capture and represent the quality characteristics
of a business process.
Inputs/Outputs Quality Dimension
Human Resource Quality Dimension
Non-Human Resource
Quality Dimension
Function Quality Dimension
Process Quality
Fig. 4.4. QoBP Framework - Quality Model - Quality Dimensions of Business Process
Four dimensions of the quality model are described in Section 4.3.2. The
business process quality dimensions proposed here are built based on the
quality models in areas that are relevant to these four dimensions. A com-
prehensive literature review was conducted to gain insight into the quality
models in the related areas. A summary of the literature review is presented
in the following section before introducing the quality model in detail in
Section 4.3.2.
4.3.1 Quality Models in Related Domains
This section presents a brief summary of the quality models in areas that
are relevant to the four dimensions of the quality model (functions, in-
60 4 The Design Science Phase
puts/outputs, human resources, and non-human resources). The proposed
quality model presented in Section 4.3.2 is built based on the quality models
from software engineering 4.3.1.1, services & web-services 4.3.1.2, data &
information 4.3.1.3, and human resources 4.3.1.4 areas. Figure 4.5 depicts
a matrix that presents how the four business process quality dimensions are
influenced by these areas. Each row in this matrix presents a business pro-
cess quality dimension and each column presents a relevant area. The cells
of the matrix therefore represent a unique quality dimension/relevant area
relationship where a ‘X’ is present indicates the existence of a relationship.
Software Engineering Services & Web-Services Data & Information Human ResourcesFunction X XInput & Output XHuman Resource XNon-Human Resource X XQoBP Dimensions
Relevant Disciplines
Fig. 4.5. Business Process Quality Dimensions - Literature Review Matrix
The justification for the influence/relevancy for each area include:
• Software Engineering - The function and non-human resource dimen-
sions of the quality model were influenced by the quality models in the
Software Engineering area. This relevancy arises from:
– Function - The similarity between a software and a business process
has been discussed in detail in [100]. In summary, both software and
business process have logical structures with inputs and outputs in
the form of functions or activities, and both have interactions with
human resources.
4.3 Quality Definition Phase - QoBP Framework Part I 61
– Non-human resource - Software is one of the common non-human re-
source element of a business process. In this case there is a direct
relevancy between quality models in Software Engineering area and
non-human resource quality dimension.
• Service & Web-Services - The function and non-human resource di-
mensions of the quality model were influenced by the quality models in
the services & web-services area. This relevancy arises from:
– Function - A synergy between a service and a function of a business
process has been acknowledged through the literature [101, 102, 103,
104].
– Non-human resource - Non-human resource elements of a business
process provide a service to the business process. For example, a tele-
phone set is a non-human resource required for the ‘receive complaints’
function of the ‘customer complains’ process within a call center. In
this case, the telephone set provides a communication service for the
‘receive complaints’ function of the ‘customer complains’ process.
• Data & Information - The input & output dimension of the quality
model was influenced by the quality models in the data & information
area. The inputs and outputs of a function within a business process cap-
ture the physical and informational objects that are used and produced
by that function; hence, a direct relevancy between the quality model in
the data & information area and the input & output quality dimension.
• Human Resources - The human resource dimension of the quality
model was influenced by the quality models in the human resource area.
The direct relevancy in this case is self-evident.
A summary of the literature review on the quality models/frameworks
in software engineering is presented in the following section.
62 4 The Design Science Phase
4.3.1.1 Literature Review on Software Engineering
In this section, a summary of the quality models within Software Engineer-
ing that have influenced both function and non-human resource quality
dimensions of the quality model (see Figure 4.5) is presented.
Evaluation of software products in order to satisfy software quality re-
quirements is an important step in the software development life cycle.
Several standards [27, 105, 106, 107, 108] by the International Organisation
for Standardization (ISO)7 and the International Electrotechnical Commis-
sion (IEC)8 have been produced to provide a framework for evaluating the
quality of a software product. The software product quality model proposed
by ISO/IEC consists of two parts: (1) internal quality and external quality,
and (2) quality in use. Internal quality represents the totality of character-
istics of the software product from an internal view, and it is measured and
evaluated against the internal quality requirements. External quality repre-
sents the totality of characteristics of the software product from an external
view, and it is measured and evaluated against external requirements. Qual-
ity in use represents the users view of the quality of the software product
in a specific context of use, and it is measured and evaluated against users
requirements on use of software in a particular environment. A software
product quality can be evaluated by measuring internal quality, external
quality, and quality in use.
The first part of the ISO/IEC model consists of six characteristics
for internal and external quality, which are further subdivided into sub-
characteristics. The six internal and external characteristics are: function-
ality, reliability, usability, efficiency, maintainability, and portability. Func-
tionality refers to the capability of the software product to provide functions
which meet stated requirements and need. Reliability refers to the capability
of the software product to performs consistently under specified conditions.
The capability of the software product to be easily understood, and learned
is referred to as usability. Efficiency is the capability of the software product
7 ISO is the world’s largest developer and publisher of International Standards. Refer tohttp://www.iso.org/iso/about.htm for further details.
8 IEC is the world’s leading organization that prepares and publishes International Standardsfor all electrical, electronic and related technologies. Refer to http://www.iec.ch/ for furtherdetails.
4.3 Quality Definition Phase - QoBP Framework Part I 63
to provide appropriate performance, under specific conditions. The capabil-
ity of the software product to be modified is referred to as maintainability.
Finally, portability defines the capability of the software product in trans-
ferring from one environment to another.
The second part of the ISO/IEC model consists of four quality in use
characteristics: effectiveness, productivity, safety, and satisfaction. Effective-
ness represents the capability of the software product in enabling users to
achieve specified goals with accuracy and completeness in a certain context
of use. The capability of the software product to enable users to be pro-
ductive is referred to as productivity. Safety represents the capability of the
software product to maintain acceptable levels of harm or risks to people
and environments in a specified context of use. Finally, satisfaction refers
to ability of the software product to satisfy users in a specified context of use.
Internal quality represents the totality of characteristics of the software
product from an internal view, and it is measured and evaluated by using
accepted set of metrics against the internal quality requirements. External
quality represents the totality of characteristics of the software product from
an external view, and it is measured and evaluated by using accepted set of
metrics against external requirements. Quality in use represents the users
view of the quality of the software product in a specific context of use. It
is measured and evaluated by using accepted set of metrics against users
requirements on the use of software in a particular environment. Software
product quality can be evaluated by measuring internal quality, external
quality, and quality in use.
As outlined in the previous section (see Figure 4.5), both function and
non-human resource quality dimensions of the quality model presented in
Sections 4.3.2.1 & 4.3.2.4 are built based on the ISO/ICE software quality
characteristics presented above.
A summary of the literature review on the quality models/frameworks
in the services and web-services area is presented in the following section.
64 4 The Design Science Phase
4.3.1.2 Literature Review on Services and Web-Services
This section presents a summary of the quality models within services and
web-services that have influenced both function and non-human resource
quality dimensions of the quality model (see Figure 4.5).
A service is considered as a set of software functionalities which facilitate
the implementation of some kinds of applications [101]. A service is viewed
as a simple or a complex task or activity, executed within an organisation on
behalf of a customer or organisation [102, 103, 104]. Services are also seen
as abstractions of business processes [108]. This abstraction being generally
performed for the purpose of service composition. Accordingly a literature
review of service quality in service & web-service management area was
conducted and is presented in this sub-section.
Quality of Service (QoS) is the quality delivered by a service, expressed
by non-functional characteristics with quantifiable parameters [109]. An en-
hanced QoS will bring competitive advantage for a service provider. The
competitive advantages of having a framework to define and evaluate qual-
ity of services has been discussed in several literature [108, 110]. As a result,
standard specifications [111, 109] have been produced to provide a frame-
work for defining and evaluating the quality of services.
The QoS framework by ISO/IEC [111] defines a number of quality char-
acteristics of particular importance and describes how QoS requirements can
be expressed and managed9. The ISO/IEC framework groups the quality
characteristics specific to the communication and processing services into
the following groups:
• Time-related characteristics such as time delay, and life time of data;
• Coherence characteristics such as temporal coherence;
• Capacity-related characteristics such as the amount of service that can
be provided at a specific time;
9 Refer to [111] for further details.
4.3 Quality Definition Phase - QoBP Framework Part I 65
• Integrity-related characteristics such as the correctness of the service pro-
vided;
• Safety-related characteristics such as the level of safety provided by ser-
vice;
• Security-related characteristics such as protection against unauthorised
access; and
• Reliability-related characteristics such as the ability of the service to op-
erate under certain conditions.
The Object Management Group (OMG)10 has produced a specification
that defines a set of UML11 extensions to represent Quality of Service (QoS).
They have proposed a general QoS catalogue that includes a set of general
characteristics and categories that are not specific to any projects or do-
mains. This catalogue includes characteristics such as:
• Performance - The timeliness aspects of a service;
• Security - The access control and confidentially;
• Integrity - The ability to provide the service that is expected;
• Coherence - The concurrent and temporal consistency of data;
• Latency - The time interval between request and response to a service;
• Efficiency - The ability to provide results with the minimum resource
consumption;
• Demand - The portion of service that is required; and
10 The Object Management Group (OMG) is an international, open membership, not-for-profitcomputer industry consortium. Refer to http://www.omg.org/ for further details.
11 The Unified Modeling Language (UML) is a standard language for specifying, visualizing,constructing, and documenting the artifacts of software systems, as well as for business mod-eling and other non-software systems. Refer to http://www.uml.org/ for further details onUML.
66 4 The Design Science Phase
• Reliability - The capability of a service to maintain a specified level of
performance.
With the proliferation of web-services as a business solution to enterprise
application integration, the quality of services offered by web services has
become crucial to both service providers and their clients. Quality of Service
(QoS) requirement for web-services proposed by the World Wide Consor-
tium (W3C) [?] has identified a set of quality characteristics for web-services
which are very similar to the quality catalogue proposed by OMG such as
security, availability, reliability.
A quality model for web-services composition has been proposed by [112]
which promotes a quality-driven approach to selection of the component ser-
vices during the execution of a composite service. The dimensions of this
quality model characterize the non-functional properties of web-services
such as: execution price, reputation, reliability, and availability. A simi-
lar but more recent work by [113] presents an extended web-service QoS
model based on a configurable fuzzy synthetic evaluation system. In their
framework, web-service QoS can be evaluated dynamically according to the
service context. Quality of Service Modeling Ontology (QoS-MO) [114] is
another example of of the quality specification for web-services. That spec-
ification presents how a QoS-MO specification can be used along the whole
life cycle of the web-service, from its design through to its utilization.
As outlined in Section 4.3.1 (see Figure 4.5), both function and non-
human resource quality dimensions of the quality model presented in Sec-
tions 4.3.2.1 & 4.3.2.4 are built based on the QoS framework for both service
and web-service management as presented above.
A summary of the literature review on the quality models/frameworks
in the data & information management area is presented in the following
section.
4.3.1.3 Literature Review on Data & Information Management
This section presents a summary of quality models within data & informa-
tion management domain that have influenced input & output dimension
4.3 Quality Definition Phase - QoBP Framework Part I 67
of the quality model.
Information & data quality has become a critical concern for organiza-
tions [56] and as a result it has been the topic of the Management Infor-
mation Systems (MIS) research for the last few decades [115, 116, 57, 117].
Two categories of data quality are identified in [57], namely data product
quality and data service quality. Data product quality includes the quality
aspects related to data itself while service quality includes aspects related
to the process of delivering information to consumers. This research is par-
ticularly interested in data product quality which focuses on the content of
data. Cykana et al [115] have proposed six data quality characteristics:
• Accuracy - Error free data;
• Completeness - Data values provided completely;
• Consistency - Data satisfies a set of constraints;
• Timeliness - Data is up to date;
• Uniqueness - Data without an equivalent; and
• Validity - Data is rigorous enough to be accepted.
Wang & Strong [117] have proposed a more extensive list of data quality
characteristics grouped into four categories: intrinsic, accessibility, contex-
tual and representational. Intrinsic data quality refers to the quality of data
in its own right and it includes characteristics such as accuracy and reputa-
tion. The quality of the data that is related to its ease of access is referred to
as accessibility. Contextual data quality is characterised by context such as
relevancy, and timeliness. Representational data quality refers to the format
and meaning of the data such as its concise representation.
As outlined in the Section 4.3.1 (see Figure 4.5), the input & output
quality dimension of the quality model presented in Section 4.3.2.2 is par-
ticulary built based on the quality characteristics identified by Wang &
Strong [117]. The list of quality characteristics provided by Wang & Strong
68 4 The Design Science Phase
[117] has influenced the the input & output quality dimension because it is
the most comprehensive and intuitively correct list.
A summary of the literature review on the quality models/frameworks
in the human resource (HR) area is presented in the following section.
4.3.1.4 Literature Review on Human Resource (HR)
This section presents a summary of quality models within human resource
(HR) that have influenced the human resource quality dimension of the
quality model.
Functions within a process may be performed by human resources (e.g.
employees), therefore they are important elements of a business process. It
has been acknowledged that quality of a business process is influenced by the
competency of the resources allocated to the process [118, 119, 120]. There
is a large amount of research on competency modelling [120, 118, 121, 122]
which is outside the scope of business process modelling. In the human re-
source management field, competency has been defined as the underling
characteristics of a person that can determine person’s performance in a
job or situation [121, 123]. A more concrete definition defines competency
based on three dimensions: resource, context and objective [124] which are
described below.
Harzallah et al [124] defines resource competency based on individuals
as:
• knowledge - It is something that individuals acquire and store intellec-
tually. Knowledge is usually gained through learning in a systematic ap-
proach such as the education system. It consists of theoretical knowledge
(for instance, knowing about Newton’s second law of gravity), knowledge
of existing things (for example, know how DNA replication works inside
a living cell), and procedural knowledge (knowledge exercised in the per-
formance of some task).
• Know-how - It is related to personal experience acquired by doing and
practicing. For example, to have experience in closing a sale in telemar-
4.3 69
keting. It is also referred to as skills or operational capabilities.
• Behaviours - These are individual characteristics that lead someone to
act in a specific way under ceratin circumstances. Behaviours often influ-
ence individual’s knowledge and experience when put in practice. They
include human attitudes, qualities and mannerism such as creativity,
self-confidence, and tenacity.
The second dimension of competency - context - is related to the en-
vironment that the competency is situated in. It represents the conditions
and constrains influencing an individual’s competency [124]. For example,
weather influences the competency of a football player during a game.
The third dimension of competency - objective - presents the mission or
goal the individual is trying to achieve.
As outlined in the Section 4.3.1 (see Figure 4.5), the human resource
quality dimension of the quality model presented in Section 4.3.2.2 is built
based on the competency model defined by [124, 120].
The above four sub-sections (Sections 4.3.1.1 to 4.3.1.4) presented the
quality models/frameworks in related areas have influenced the proposed
quality model in this study. The following section describes the quality model
that was briefly introduced at the beginning of Section 4.3.
4.3.2 QoBP Framework - Quality Model
In this section we present the quality model proposed by this thesis. The
quality model was briefly introduced at the beginning of Section 4.3. As
shown in figure 4.4, quality of a business process is based on four distinct
dimensions: quality of functions, quality of input and output objects, quality
of human resources, and quality of non-human resources. In this section each
dimension is described in terms of its quality characteristics. The function
quality dimension and its quality characteristics are described in the fol-
lowing section (Section 4.3.2.1). Section 4.3.2.2 presents the input&output
quality dimension, followed by Section 4.3.2.3 which presents the human re-
70 4 The Design Science Phase
source quality dimension. Section 4.3.2.4 presents the non-human resource
quality dimension.
4.3.2.1 Function Quality Dimension
The purpose of this section is to present the quality characteristics for the
function quality dimension. A function is a basic building block in a business
process that corresponds to an activity (task, process step) which needs to
be executed [125]. As depicted in Figure 4.5, the function quality dimension
is built based on the quality models in software engineering (Section 4.3.1.1)
and services & web-services (Section 4.3.1.2) areas. The quality characteris-
tics for the function dimension are specifically built based on the ISO/ICE
software quality characteristics [27] and quality characteristics of the QoS
framework for both service [111, 109] and web-service [53] management. The
function quality characteristics of the quality model are presented below.
Suitability - Refers to the capability of the function to meet specified
objectives. For example, suitability for capture incident details function of
the insurance claim process means incident details are captured adequately
and completely.
Accuracy - Refers to the capability of the function to provide the right
or agreed results or effects with the needed degree of precision. For exam-
ple, accuracy for validate incident coverage function of the insurance claim
process means that validation needs to follow explicit rules to produce an
accurate result.
Security - Relates to the capability of the function to protect infor-
mation and data so that unauthorised resources cannot access them. For
example, security for capture policy details of the insurance claim process
means an authorised resource can only perform this task and an audit trail
of the resource for this function is required.
Reliability - The capability of the function to be in a state to perform
under stated conditions at a given point in time. For example, obtain policy
details and validate caller function of the insurance claim process must be
4.3 71
available all the time (24 hours a day, 7 days a week).
Robustness - The degree to which a function can operate correctly even
in the presence of invalid, incomplete or conflicting inputs. For example, as-
sess liability function of the insurance claim process is required to be robust
and reliable under any circumstances, to produce a correct outcome.
Understandability - The capability of the function to enable the re-
source to understand whether the function is suitable, and how it can be
used for particular functions and conditions of use. For example, a resource
who performs the validate policy function of the insurance claim is required
to have a very good understanding of how to perform this validation.
Learnability - The capability of the function to enable the resource to
learn it. For example, a resource should be able to learn easily how to per-
form action hire car and towing function of the insurance claim process.
Time efficiency - The capability of the function to provide appropriate
response and processing times under stated conditions. For example, cap-
ture incident details function of the insurance claim process is required to
be performed in a timely manner.
Resource utilisation - The capability of the function to use appropriate
amounts and types of resources under stated conditions. For example, ob-
tain policy details and validate caller function of the insurance claim process
should utilise the resources to maintain an appropriate level of efficiency.
Effectiveness - The capability of the function to enable resources to
achieve specified goals with accuracy and completeness in a specified con-
text. For example, the resource who is allocated to perform finalise claim
intake function of the insurance claim should finalise the claim completely
with minimum number of errors, in an adequate amount of time.
Productivity - The capability of the function to enable resources to
be effective in a specified context. For example, obtain policy details and
72 4 The Design Science Phase
validate caller function of the insurance claim process should enable the
resource performing the function in an appropriate amount of time, using
the minimal resources required.
Safety - The capability of the function to achieve acceptable levels of
risk of harm to people, process, property or the environment.
Satisfaction - The capability of the function to satisfy users in a speci-
fied context. For example, obtain policy details and validate caller function
of the insurance claim process should be performed with the goal to satisfy
the caller.
Note that these characteristics can be relevant for a function, but not all
are applicable for every function. For example, safety is not necessarily an
applicable quality characteristic for validate policy function of the claim in-
surance process. Having this list of characteristics helps the analyst identify
quality aspects of particular functions of an individual process.
The Input & output quality dimension and its quality characteristics are
described in the following section.
4.3.2.2 Input and Output Quality
This section presents the quality characteristics for the input & output qual-
ity dimension. The input and output of functions within a business process
capture the physical and informational objects that are consumed and pro-
duced by it. Inputs and outputs quality contribute to overall process quality.
The characteristics presented below help to identify the quality aspects of
inputs and outputs.
As depicted in Figure 4.5, the input & output quality dimension is built
based on the quality models in the data & information area (Section 4.3.1.3).
The quality characteristics for the input & output dimension are specifically
built based on the data quality characteristics defined by [117] which build
on the overarching quality categories: intrinsic, contextual, representation,
and accessibility. Input & output quality characteristics of the quality model
4.3 73
are presented below.
Accuracy - Refers to whether the data accurately records the business
object or event it represents. For example, incident details captured during
the capture incident details function of the insurance claim process must
accurately represent the incident (details such as date of the incident, car
involved in the accident, and driver’s details).
Objectivity - Refers to whether the data is unbiased and factual. For
example, no judgement should be made on incident details while being cap-
tured during the capture incident details function of the insurance claim
process. Incident details should be unbiased and factual.
Believability - Refers to the extent to which data are accepted or re-
garded as true, real and credible. For example, the incident details required
for an insurance assessor to assess liability (assess liability function of the
insurance claim process) must be real and credible.
Reputation - Refers to the extent to which the data has a reputable
source. For example, customer information must be gathered from a rep-
utable source during the obtain policy details and validate caller function
of the insurance claim process.
Accessibility - Refers to the extent to which data is easily accessible
when needed. For example, assessment details must be easily accessible dur-
ing the finalise claim intake function of the insurance claim process.
Security - The extent to which data is protected against unauthorised
access. For example, other party details which is data required for add autho-
rised parties function of the insurance claim process needs to be protected
against unauthorised access.
Relevancy - Refers to the extent to which the data is relevant. For ex-
ample, customer vehicle details required for assess pathing function of the
74 4 The Design Science Phase
insurance claim process must be relevant to the claim being assessed.
Value-added - The extent that data contributes to value creation. For
example, the incident details captured during the capture incident details
function of the insurance claim process should add value to the process.
Timeliness - The extent to which the data is sufficiently current. For
example, the coverage and policy extras required for validate incident cover-
age function of the insurance claim process must be up-to-date and current.
Completeness - The extent to which the data includes all necessary
values. For example, incident details required for assess liability function of
the insurance claim process should contain all the details required.
Amount of data - Relates to a sufficient data volume. For example,
incident details should capture all the necessary details about the accident
during the capture incident details function of the insurance claim process.
Understandability - The extent to which the data is comprehended.
For example, incident details should include all the necessary information
about the accident to ensure comprehensiveness of the details.
Concise representation - Relates to the extent to which the data is
compactly represented. For example, incident details presented to the claim
assessor should be presented compactly to increase the readability of the
data.
Consistent representation - Refers to the extent in which the data is
presented in the same format. For example, the coverage and policy extras
should be presented in the same format for all cases.
Note that these characteristics can be relevant for an input or output, but
not all are applicable for every input & output. Having this list of charac-
teristics helps the analyst identifying quality aspects of particular inputs or
4.3 75
outputs of functions of an individual process.
The human resource quality dimension and its quality characteristics are
described in the following section.
4.3.2.3 Human Resource Quality
The purpose of this section is to present the quality characteristics for the
human resource quality dimension. Functions within a process may be ex-
ecuted by human resources (e.g. employees). It has been well recognised
that quality of a business process is influenced by the competency of the
resources allocated to the process [119, 120]. Still, most business process
modelling techniques lack the capability to capture the competency require-
ments needed to execute a function within a business process [120]. As de-
picted in Figure 4.5, the human resource quality dimension is built based on
the quality models in the human resource (Section 4.3.1.4) area. The quality
characteristics for the human resource dimension are specifically built based
on the work in [121, 123, 124, 120]. Human resource quality characteristics
of the quality model are presented below.
Domain knowledge - The knowledge on a specific domain that a hu-
man resource must have acquired for to be able to perform the function.
For example, a broad knowledge on claims process is required for the claim
processor in informing customer of next steps function.
Qualification - Qualification a human resource needs in order to per-
form the function. For example, a General Practitioner is required to have
medical qualifications to prescribe medicine to a patient.
Certification - Certification relates to a certificate that a human re-
source should have to perform the function. For example, a stock broker
requires to have a specific certification to be able to provide advisory com-
ments to his clients.
Experience - Experience that a human resource has acquired that is
relevant to the function. For example, data entry experience is necessary
76 4 The Design Science Phase
for the claim processor who captures incident details in the insurance claim
process .
Time management - A behavior that a human resource need to demon-
strate to be able to perform the function. For example, time management
is a necessary skill for the claim processor who assesses the liability in the
insurance claim process.
Communication skill - A behavior that a human resource needs to
demonstrate to be able to perform the function. For example, the claim
processor who obtains policy details to and validates caller in the insurance
claim process must be able to elicit information from the claimant.
Non-human resource quality dimension and its quality characteristics are
described in the following section.
4.3.2.4 Non-human Resource Quality
This section presents the quality characteristics for the non-human resource
quality dimension. Functions may be executed by non-human resources such
as machines, devices, or software programs. The way these non-human re-
sources operate influences the quality of functions and the business pro-
cess as a whole. As depicted in Figure 4.5, the non-human resource quality
dimension is built based on the quality models in the software engineer-
ing (Section 4.3.1.1) and services & web-services (Section 4.3.1.2) areas.
The quality characteristics for the function dimension are specifically built
based on the ISO/ICE software quality characteristics [27] and quality char-
acteristics of the QoS framework for both service [111, 109] and web-service
[53] management. Non-human resource quality characteristics of the quality
model are presented below.
Suitability - The capability of the resource to provide an appropriate
function for specified user objectives. For example, claims system is a re-
source for obtain policy details and validate caller function of the insurance
claim process. It should provide functionality to capture customer identifi-
4.3 77
cation and retrieve the policy and product details for that customer.
Accuracy - The capability of the resource to provide the right or agreed
results or effects with the needed degree of precision. For example, claims
system is a resource for obtain policy details and validate caller function of
the insurance claim process. It should retrieve the caller information accu-
rately.
Security - The capability of the resource to protect information and
data so that unauthorised resource cannot access to them. For example,
claims system is a resource for add authorised parties function of the insur-
ance claim process. It must record audit trail of the human-resource who
added authorised parties to a claim.
Reliability - The capability of the resource to be in a state to perform
under stated conditions at a given point in time. For example, claims sys-
tem is a resource for obtain policy details and validate caller function of the
insurance claim process. It should be available all the time (24 hours a day,
7 days a week).
Robustness - The degree to which a resource can function correctly
even in the presence of invalid, incomplete or conflicting inputs. For exam-
ple, claims system is a resource for obtain policy details and validate caller
function of the insurance claim process. It should be robust and reliable to
provide the caller validation functionality.
Time behaviour efficiency - The capability of the resource to provide
appropriate response and processing times and throughput rates when per-
forming its function, under stated conditions. For example, claims system
is a resource for obtain policy details and validate caller function of the in-
surance claim process. It should identify caller in a timely manner.
Resource utilisation - The capability of the resource to use appropri-
ate amounts and types of resources under stated conditions. For example,
claims system is a resource for finalise claim intake function of the insur-
78 4 The Design Science Phase
ance claim process. It should perform this task with using the minimum
resources available.
Effectiveness - The capability of the resource to achieve specified goals
with accuracy and completeness in a specified context of use. For example,
claims system is a resource for the assess excess function of the insurance
claim process. It should provide appropriate functionality to assess the ex-
cess based on policy coverage, vehicle information, and incident details.
Safety - The capability of the resource to achieve acceptable levels of
risk of harm to people, process, property or the environment in a specified
context of use. For example, a radiologist is required to follow certain safety
rules while taking an X-Ray for a patient.
Satisfaction - The capability of the resource to satisfy resources in a
specified context of use. For example, claims system is a resource for the
capture incident details function of the insurance claim process. It should
create a satisfactory experience for the claim processor.
A summary of the contents of this section is presented in the following
section.
4.3.3 Summary of QoBP Framework Part I
This Section (Section 4.3.2) presented the quality model, and its four qual-
ity dimensions (function, input & output, human resource, and non-human
resource) in terms of quality characteristics. A justification for developing
such a model was presented at the beginning of the section, followed by a
comprehensive literature review of the relevant areas influencing the qual-
ity characteristics defined for the business process quality dimensions (see
Section 4.3.1). An overview of the four quality dimensions and their char-
acteristics presented in this section is provided in Figure 4.6. As discussed
in Section 4.3, the quality model provides a structured approach to capture
and represent the quality characteristics of a business process.
4.3 79 F u n ctio n In p u t /
O u tp u t N o n -h u m a n R e so u rce
H u m an R eso u rce Suitab ility O bjectivity Su itab ility D o m ain Know ledge A ccuracy A ccuracy A ccuracy Q ualification Security Secu rity Security C ertification Reliab ility B elievability Reliab ility Experience U nderstandability Reputation T im e Efficiency T im e M anagem ent Learnability A ccessib ility Resource - U tilisation C om m unication Skills T im e Efficien cy T im eliness Effectiveness Resource – U tilisation V alue-add ed Safety Effectiveness Relevancy U ser Satisfaction Productivity Com pleten ess Robustness Safety A m ount of D ata A vailab ility U ser Satisfaction Robustness
Fig. 4.6. QOBP Quality Dimensions & Characteristics
The quality characteristics defined for the four dimensions of a business
process were built based on the quality models in related areas, and their ap-
plicability and relevancy to the business process dimensions was thoroughly
examined using a working example which is the case of a software project
process (Request for Proposal - RFP) that is used by Software House (SH)
for responding to tenders [126]. The applicability and relevancy of the qual-
ity characteristics to the business process dimensions will be evaluated in
real world cases during the action research phase12.
Next section (Section 4.4) presents the additional artifacts of the QoBP
framework developed to support the quality definition phase of the quality-
aware BPM life cycle.
12 Refer to the first evaluation objective described in Section 5.3.5.
80 4 The Design Science Phase
4.4 Quality Definition Phase - QoBP Framework Part
II
The purpose of this section is to present the additional artifacts of the
QoBP framework developed in this thesis to support the quality definition
phase of the quality-aware BPM life cycle (highlighted orange in Figure 4.3).
The description of quality with respect to a business process and the
quality model were introduced in Section 4.3. In this model, the quality of
a business process is defined based on four dimensions: function, input &
output, human resource and non-human resource. The quality model further
defines each quality dimension in terms of its relevant quality characteris-
tics. As described in Section 4.1, in the QoBP framework the quality model
proposed in Section 4.3 is utilised to create a quality-aware business process
model.
The QoBP framework provides additional models that supplement the
quality model in order to define measurable attributes (referred to as quality
metrics) for the quality characteristics of the quality model.
The QoBP framework supports a goal-driven measurement approach
that is presented in Section 4.4.1. The justification for choosing a goal-
driven approach is also presented in Section 4.4.1. The adapted goal-driven
measurement approach, with respect to the QoBP framework, results in
three models which are presented in Sections 4.4.2, 4.4.3, and 4.4.4. Sec-
tion 4.4.2 presents the softgoal model that models the quality character-
istics of the quality model as a set of softgoals. Section 4.4.3 presents the
softgoal correlation model that models the relationships between these
softgoals. Section 4.4.4 presents themeasurement model which represents
how quality characteristics, described in the form of softgoals, are evaluated.
An extension to the EPC notation13 is proposed to embed these models
into a business process model (see Section 4.4.5.2). Section 4.4.6) introduces
a methodology for the quality definition phase which provides a step-by-step
13 Event-Driven Process Chain (EPC) is a business process modelling notation. Refer to Ap-pendix A.1 for further details on EPC.
4.4 81
procedure to create a quality-aware business process model.
The next section presents the goal-driven measurement approach adapted
by this research. This section is structured to provide answers to the ques-
tions: what will be measured; why does it need to be measured; and how
will it be measured.
4.4.1 Goal-driven Measurement Approach
This section presents the goal-driven measurement approach proposed by
this research to measure the quality characteristics of the quality model.
The approach has been developed based on a comprehensive literature re-
view in related areas and ir extends existing approaches and frameworks.
Before presenting a summary of the literature review (in Section 4.4.1.1),
an explanation is provided on: what needs to be measured, why it needs to
be measured and how it will be measured.
The main purpose of the quality framework introduced in this section
is to incorporate the quality requirements into a business process model in
the form of quality characteristics producing a quality-aware business pro-
cess model. These quality characteristics will required to be measured during
the quality control phase of the quality-aware BPM life cycle (Figure 4.3).
The quality characteristics are evaluated for an enacted process to ensure
the desired level of quality is achieved for that process. This measurement
will also assist in predicting the quality issues in cases where the quality
requirements are not met and also in improving the quality by identify-
ing roadblocks. For example, a hypothetical mortgage company is keen to
increase the quality of the loan application process, specifically to reduce
the loan approval processing time of the loan approval function. Ongoing
measurement of the quality characteristic time efficiency during the pro-
cess enactment is necessary to monitor the achievement of the original goal
- “increase the time efficiency of the loan approval function”.
In general, there are four reasons to measure [127]; these four reasons
with respect to the business process quality measurement are as follows:
82 4 The Design Science Phase
• To characterise - to gain understanding in order to establish baselines
for comparisons. For example, in order to compare the time efficiency of
different instances of a loan approval process.
• To evaluate - to assess achievement of quality goals. For example, to
evaluate if the loan approval has met its quality goals with respects to
the time efficiency.
• To predict - to determine quality issues. For example, in the loan ap-
proval scenario, to detect the possibility of quality issues if the loan
approval takes longer than 3 weeks (having a target threshold of 2 weeks
maximum).
• To improve - to identify roadblocks, root causes and improvement op-
portunities. For example, measuring the time efficiency of the loan ap-
proval process will assist in the identification of the root causes of quality
issues related to the timeliness and opportunities for improvement.
The four reasons listed above confirm that the measurement of the qual-
ity characteristics are necessary to support the full life cycle of a quality-
aware business process.
The measurement of a quality characteristic is a complicated task due to
the multi-facetted nature of quality characteristics[128]. Similar to quality
(non-functional) requirements in Requirement Engineering14 [128], the qual-
ity requirements of a business process in the form of quality characteristics
are often subjective, implicit, context-specific and imprecise. Subjectivity
results from the fact that different people can evaluate a quality character-
istic differently. For example, in a software company, the account manager
may have a different view of the completeness of the estimate function than
the software development manager, who may, in turn, have a different view
than the quality manager. A quality characteristic is implicit, meaning it is
implied rather than expressly stated. For example, an implicit quality char-
14 Requirements Engineering is the process of discovering the purpose a software system isintended for by identifying stakeholder, stakeholder’s needs, and documenting these in a formthat is amenable to analysis, communication, and subsequent implementation within SoftwareEngineering [129].
4.4 83
acteristic of the estimate function is accuracy. Context-specificity entails
that a quality characteristic may have a different meaning for each process
instance. For example, relevancy of the estimate function for a large soft-
ware quote (say over $1,000,000) may be different to a software quote of
lower value (say $10,000 - $50,000). A quality characteristic being imprecise
stems from the inability to define the characteristic exactly. For example, it
is difficult to define what understandability means to the estimate function
and how it can be measured. Therefore, to measure quality characteristics,
they are required to be further refined to a set of measurable attributes.
As mentioned briefly at the beginning of Section 4.4, the QoBP frame-
work provides additional models that supplement the quality model15 to
define a set of measurable attributes, referred to quality metrics, for the
quality characteristics. These quality metrics are essential for the measure-
ment of the quality characteristics. This section presents these additional
models of the QoBP framework which are based on a systematic goal-driven
approach to identify measurable quality metrics for the quality characteris-
tics of a business process. Before presenting these models a summary of the
literature review on the related areas is presented (in the next section) to
provide a background on why a goal-driven approach is selected.
4.4.1.1 Literature Review on Measurement Approaches
The purpose of this section is to provide a summary of the literature review
conducted to gain insight into measurement approaches in relevant areas of
study.
As stated in Section 2.3.1, in the context of this research, the term qual-
ity refers to the non-functional characteristics of a business process. This
definition is adopted from the Software Engineering discipline where non-
functional requirements are referred to as quality requirements. The ap-
proaches for non-functional requirements are classified into product-oriented
and process-oriented [130]. Product-oriented approaches evaluate the de-
gree of compliance with non-functional needs by measuring how software
15 Refer to Section 4.3 for further details on the quality model.
84 4 The Design Science Phase
complies with non-functional requirements. Process-oriented approaches are
concerned with the software development process, by ensuring alternative
software designs are searched to sufficiently meet non-functional require-
ments. Accordingly, a comprehensive literature review has been conducted
to gain insight into how quality (non-functional) characteristics of a soft-
ware product are measured and evaluated.
ISO/IEC standards [27] define measurement as “the use of a metric to
assign a value (which may be a number or category) from a scale to an
attribute of an entity”. Software products are evaluated by measuring the
quality characteristics in the form of metrics [105, 106, 107, 131]. ISO/IEC
has recommended a set of metrics to measure software quality character-
istics. These metrics are not intended to be exhaustive and may not be
applicable to every evaluation case. For instance, the number of detected
failures is one of the metrics recommended for measuring the reliability of
software [107]. Each metric is evaluated using a standard measuring scale.
The measuring scale provides values and units for describing metrics [127].
ISO/IEC standards [105, 106, 107] recommend a measuring scale which is
mostly based on Stevens [132] scale types. The measuring scales recom-
mended by ISO/IEC [105, 106, 107] consist of:
• Nominal scale - This scale is used when a determination for equality
is required. The value of this scale is interpreted as a unique identifier.
Nominal scale presents a one-to-one mapping [105], for example, software
fault type is data.
• Ordinal scale - This scale represents the operation of rank ordering.
For example, the software failure by severity may be negligible, marginal,
critical, catastrophic.
• Ratio scale - This type represents ordered rating scales, where both
the difference between two measures and the proportion of two measures
have the same empirical meaning. Length is an example of ratio scale,
as 2 metres is twice as long as 1 metre.
4.4 85
• Interval scale - This scale presents an ordering scale where two mea-
sures are different in empirical meanings. A typical example of interval
scale is temperature in Fahrenheit.
As outlined above, the ISO/ISE’s measurement approach to evaluate
quality characteristics of a software product is based on using a pre-defined
set of metrics. Evaluations based on a set of pre-defined metrics while pro-
viding a generic evaluation framework, do not directly support an organi-
sation’s business goals and objectives for a specific software product [127].
Using a goal-driven approach in defining software measures that directly
support an organisation’s business goals and objectives has been proven to
be successful in assuring that the identified metrics are relevant and are
effectively utilised [127]. Therefore, a thorough literature review is specifi-
cally conducted in the goal-driven approaches (for both softgoals and hard
goals) in Requirements Engineering (RE) within the Software Engineer-
ing discipline. In the Software Engineering discipline, hard goals, usually
just referred as goals, are used to define the functional requirements16 of
the system, while softgoals are used to define non-functional17 (quality) re-
quirements. A softgoal is similar to a hard goal except that the criteria for
whether a softgoal is achieved are not often clear-cut and a priori [128]. In
this section, a summary of the measurement approaches in the Software En-
gineering discipline is presented in this order: several goal-driven approaches
used during different stages of Requirements Engineering such as i* model,
KAOS, GBRAM, Tropos, and Goal-Question-Metric (GQM), and softgoal
modelling. A summary of goal-driven approaches in the business process
modelling and their relevancy to this research is also presented in this sec-
tion.
Goal modelling has been used widely in Requirements Engineering (RE)
[133, 134, 135, 136, 137, 138]. Goal modelling is used during the three stages
of RE: requirements elicitation, requirements specification and requirements
16 Functional requirements are used to represent services that the software is expected to deliver(e.g. “calculate end of year tax” is a functional requirement of an accounting system).
17 Non-functional requirements refer to quality requirements that the software needs to satisfywhile delivering the services (e.g. “calculate end of year tax accurately).
86 4 The Design Science Phase
validation [139, 140, 141]18. The i* model, KAOS, GBRAM, Tropos and
Goal-Question-Metric (GQM) are examples of goal-oriented requirements
engineering and are briefly described below. The i* model and Tropos (which
is based on i* model) are goal oriented approaches that are used during
the requirement elicitation stage of Requirement Engineering. The KAOS
and GBRAM approaches are mainly used during the requirement specifica-
tion. The Goal-Question-Metric (GQM) approach is only used during the
requirement evaluation stage of Requirements Engineering. While a short
summary of these goal-oriented requirement engineering approaches is pre-
sented below, however GQM is the only relevant approach to this study as
it is dedicated to the requirement evaluation stage of Requirements Engi-
neering. This study is adopting a similar approach to evaluate the quality
requirements of a business process which are defined in the form of quality
characteristics19.
The i* model [142] is an agent-oriented approach to Requirements En-
gineering with a focus on the intentional characteristics of the agent. The
i* model provides a framework that supports a uniform approach in the
analysis of a system’s requirements - functional and non-functional [143]
during the requirement elicitation stage [144]. The fundamental concepts
of i* model are actors20, goals and actor dependencies. Goal modelling
in i* model is based on three reasoning techniques: means-end analysis21,
contribution analysis22, and AND/OR decomposition23. Tropos [143] is an
example of software development methodology based on i* model in which
18 During the requirements elicitation stage, goal modelling can be used to elicit the needs andconstraints on the system being developed. Specification of the requirements in the form of arequirements model is performed during the requirements specification stage. Finally, duringthe validation stage the requirements model is validated against the original stakeholderneeds.
19 Refer to Section 4.4.1.2 for further details on the goal-driven measurement approach adoptedby this research.
20 Actors are entities that have strategic goals and intentionality within the system or theorganisational setting [143]. Actors represent agents. The agents represent people, machinesor software within an organisation and they usually occupy positions, and as a result, theyplay the roles offered by these positions.
21 Means-end analysis is a reasoning technique based on identifying plans, resources and softgoalsthat provide a means for achieving a goal [138].
22 Contribution analysis is a reasoning technique that identifies goals that can contribute posi-tively or negatively in the fulfillment of the goal to be analysed [138].
23 AND/OR decomposition is a reasoning technique that combines AND and OR decompositionsof a high level goal into sub-goals [138].
4.4 87
goal modelling is used as a technique for requirements engineering.
KAOS (Knowledge Acquisition in autOmated Specification) [133] is an-
other goal-driven approach in Requirements Engineering which is mainly
used during the requirement specification stage [144]. This approach is based
on explicitly representing and modelling organisational goals. In KAOS,
goals are conceptually modeled in a hierarchy of parent goals and their re-
finements into sub-goals. Goals that are in higher levels of the hierarchy
represent the high-level goals (i.e. strategic concerns) of the organization.
These goals are then distilled down the hierarchy into sub-goals that have
more operational concerns.
GBRAM [145, 146] is another goal-oriented requirement engineering ap-
proach in which software problems are characterised, classified and analysed
as goals before being solved. This approach is also mainly used during the
the requirement specification stage [144].
The Goal-Question-Metric (GQM) approach by [147] is a well known
goal-oriented measurement method [148] which is mainly used during the
requirement evaluation stage [144]. Contrary to the ISO/IEC approach to
measurement, which is based on using a pre-defined set of metrics, the
GQM approach is based on eliciting high level user requirements as goals,
and questions as drivers for finding metrics. The application of GQM results
in a measurement model containing three levels: (1) a conceptual level, re-
ferred to as the definition of the goals, (2) an operational level, consisting of
a set of questions regarding the specific goals, and (3) a quantitative level,
identifying a set of metrics to be associated to each question. GQM is a
top-down approach that is known to produce effective metrics as they are
derived from goals that represent user requirements [149]. Park et al [127]
has proposed a goal-driven process based on GQM to define software mea-
sures that directly support an organisation’s business goals and objectives
[127]. They have extended the GQM approach by inserting an Indicator
step in the GQM paradigm, making it GQ(I)M. The Indicator is simply a
picture or display of one or more measurement results (for example, in the
form of a graph) that is designed to communicate or explain the significance
88 4 The Design Science Phase
of those results to help answer the question.
Softgoal modelling is process of structuring and modelling softgoals for
representing and reasoning about non-functional (quality) requirements
such as security, performance, maintainability. Softgoal modelling is a com-
mon practice during the early stages of the requirements engineering process
[150, 151, 152, 128]. In non-functional requirements engineering, softgoals
describe quality requirements in abstract terms [128]. Goal-Centric Trace-
ability [150] is an example of a goal-driven approach for modelling non-
functional requirements. This approach utilises Softgoal Interdependency
Graphs (SIG) to model non-functional requirements. In SIG, softgoals are
decomposed into sub-softgoals describing desired qualities of the system.
There have also been substantial work on goal-oriented approaches to
business process modelling [153, 154, 155, 156]. In most of these approaches,
business process modelling is influenced by business goals and objectives
that are captured during the early stages of the modelling. The business
goals defined for a process are usually refined until they can be transformed
into the functions of the process [155]. The value-focused business process
modelling approach proposed by [156] is slightly different from other ap-
proaches [153, 154, 155], in which goals are presented in the form of objec-
tives and values. However, in these approaches, goals are viewed as external
concepts, not integrated with process models [157]. These approaches also do
not support quality (non-functional) goals of a business process. The goal-
oriented approaches to business process modelling by [158, 138, 157, 159]
are the most relevant to this study. These approaches are discussed below.
Kavakli et al. [158] address business process modelling using a goal-driven
approach which is part of a larger enterprise knowledge modelling frame-
work, known as the EKD approach. They argue that the ultimate purpose of
business process modelling is to improve an enterprise in order to deal with
change; therefore, change management is the process of identifying business
goals and relating business processes to these goals. In their approach, goals
related to a business process present a hierarchical structure in which indi-
vidual goals constitute refinements of higher-level goals. In this framework,
4.4 89
goals are viewed as external concepts that are not integrated with process
models. Their framework also does not provide the capability to evaluate
these goals during different phases of the business process life cycle, its use
is limited to the analysis phase of the BPM life cycle. The satisfaction of
the original business goals during the other five phases of the BPM life cycle
(design, implementation, enactment, monitoring and implementation) are
disregarded in this framework. The evaluation of the defined goals during
the enactment and monitoring phases of the BPM life cycle is important
because it provides the capability to measure the satisfaction of the original
business goals for an implemented change.
Goal modelling has also been used in Business Process Re-engineering,
where several process alternatives are generated using Process Re-engineering
i* Method (PRiM) [138]. The PRiM methodology is based on the i* model
[142] in which the rationale behind the business process design is modelled
by means of intentional concepts. The PRiM methodology is composed of
six phases: (1) analysis of the current process, (2) construction of the i*
model of the current process, (3) re-engineering the current process, (4)gen-
eration of alternatives, (5) evaluation of the alternatives, and (6) specifi-
cation of the new system. During the first phase , the current process is
analysed using human activity models (HAMs)24 and the information ob-
tained in these models is then summarised into Detailed Interaction Scripts
(DIS)25 which is practically the detailed description of HAMs. An i* model
of the current system is constructed during the second phase. The i* model
constructed at this stage consists of two models: Operational i* Model and
Intentional i* Model. Operational i* Models are composed of resources,
tasks and some goals. Intentional i* Models supplement Operational i*
Models by representing the intentionality behind the analysed process via
additional goals and softgoals. The current process is engineered during the
third phase. This re-engineering may involve improvement to some aspects
24 Human activity modelling represents the behaviour of human actors in the process and pro-duces two deliverables: Context Models and Human Activity Models [138]. Context Modelis an extended data flow diagram that provides extra notations for actors (resources) of aprocess. Each Context Model describes the system actors, their involvement in the currentprocess and data flows between them. Human Activity Models (HAM) in PRiM are struc-tured descriptions of the current behaviour of actors with respect to goals [138].
25 ADIS contains the activity preconditions, post-conditions, triggering events, and a descriptionof the actions and the resources involved in the activity [138].
90 4 The Design Science Phase
of the current process, and introduction/change/deletion of goals and soft-
goals in i* models. During the fourth phase, i* models are used to generate
the process alternatives. PRiM generates the process alternatives by using
means-end reasoning26 and hierarchical decomposition of tasks into their
intentional elements. The new process alternatives are generated by the ad-
dition of new actors and the reallocation of responsibilities between them.
These process alternatives are then evaluated during the fifth phase and
one process is selected. During the last phase of PRiM, the new system
specification is defined27. PRiM provides a goal-driven approach for system
specifications which are based on business process re-engineering. In this
approach, the i* model is used to generate the process alternatives. It is
not clear though how the trade offs between functional and non-functional
goals are performed during this phase (phase four) as each represent dif-
ferent types of requirements for a process28. The notion of softgoals and
their roles in the generation of the process alternatives are loosely defined.
The goals modeled in the Intentional i* Model represents the intentions of
actors (resources) in a business process. It is not clear how goals related
to the other dimensions of a business process, such as data or non-human
resources, are analysed and modelled. This work is also limited to actor
modelling in which a business process is modelled based on the situated be-
haviour of actors in the process. Therefore, a gap exists for activity-oriented
(control flow) business process modelling approaches where a process is de-
scribed as a set of ordered activities (e.g. EPC29, and Petri nets 30).
Soffer and Wand [157, 159] have proposed a Generic Process Model
(GPM) that provides clear-cut criteria for evaluating process model validity
based on the integration of goals into process models. In this framework,
26 Means-end reasoning techniques in i* modelling was described earlier is this section.27 Grau et al. [138] argue that business process re-engineering provides an adequate framework
for information systems specification.28 Functional goals (also referred to as hard goals) represent functional requirements of a process
(e.g. “loan approval is performed”), while non-functional goals (also referred to as softgoals)represents the non-functional (quality) requirements that a process needs to satisfy whileenacted (e.g. “loan approval is performed in a timely manner”). Unlike non-functional goals,the achievement criteria for functional goals are sharply defined [160]. The evaluation criteriafor whether non-functional goals are achieved are not often clear-cut [128].
29 Event-Driven Process Chain (EPC) is a business process modelling notation. Refer to Ap-pendix A.1 for further details on EPC.
30 Petri nets is a business process modelling notation. Refer to Appendix A.1 for further detailson Petri nets.
4.4 91
validity is defined as the possibility of the process to achieve its goal. Goals
are formally defined as a set of stable states by a condition. Soffer and Wand
[157] relate the notion of a goal to a process by this definition: “a goal G will
be said to be a process goal if every execution of the process terminates in
G”. A process model is called a valid model with respect to a given goal in
this framework, if “there exists at least one successful process path”. Their
research appears to provide the closest alignment to our research by dis-
cussing how far control flow supports the achievement of goals of a process.
Accordingly, selecting a goal-oriented approach is a complement to the re-
search by Soffer and Wand [157, 159].
The advantages of using a goal-driven approach in business process mod-
elling, specifically during the analysis and design phases of the BPM life
cycle, has been well justified by earlier work in the area (see [155, 155, 158,
153, 154, 157, 159, 138]). As outlined above, in most of these approaches,
goals are viewed as external concepts that are not integrated with process
models, therefore goals will not contribute to the business process life cycle
after the design stage. These approaches also lack the capability to evaluate
the defined goals for a business process during the different phases of the
BPM life cycle which is a major gap in goal-oriented business process mod-
elling. The advantages of evaluating the defined goals for a business process
during the different phases of the BPM life cycle include:
• Evaluation during the implementation phase ensures the implementation
of the process is in accordance to the originally defined business goals.
• Evaluation during the enactment and monitoring phases provides the
capability to enforce the original business goals in a proactive way.
• Evaluation during the evaluation phase contributes to business process
improvement. This reactive evaluation assists with the identification of
past business process instances that have not achieved the original busi-
ness process goals. Further investigations of these cases can lead to im-
provement opportunities for future enactments of the business process.
92 4 The Design Science Phase
It can be argued that this evaluation gap has a more significant effect on
the non-functional (quality) goals than functional goals. Because in most
of these approaches the functional goals of a business process are refined
into lower level functional goals that are directly mapped to the functions
(activities) of the process. While the achievements of the higher level goals
are ignored, the achievements of the lower level functional goals can be de-
termined by successful execution of functions (activities). This is not the
case for non-functional (quality) goals (hereafter referred to as softgoals).
Therefore the quality requirements of a business process, that are defined in
the form of non-functional goals during the analysis & design phases of the
BPM life cycle are, disregarded during the later phases of the BPM life cycle.
The goal-driven approach proposed by this research addresses the short-
comings of the earlier approaches in this area by: (1) specifying and mod-
elling the quality goals of business processes (for four dimensions: function,
input & output, human resource, and non-human resource) in a structured
and systematic approach; (2) and providing the capability to evaluate these
quality goals during different phases of the BPM life cycle.
Based on the above background, a goal driven measurement approach
is adapted by this research to assure a successful identification of qual-
ity metrics for a business process that are relevant and effectively utilised.
The following section provides a summary of the goal-driven measurement
approach proposed by this research which is based on several techniques
outlined above (such as GQM, and softgoal modelling in Requirements En-
gineering).
4.4.1.2 Summary of Goal-driven Measurement Approach
The purpose of this section was to present the goal-driven quality measure-
ment approach in the QoBP framework proposed by this thesis. Section
4.4.1 briefly outlined why it is essential to measure the quality characteris-
tics of a business process. It was discussed how quality metrics need to be
identified for the quality characteristics of a business process to enable the
measurement of the quality characteristics during the enactment, monitor-
ing and evaluation phases of the quality-aware BPM life cycle. The QoBP
4.4 93
framework utilises a goal-driven approach to ensure the measurement of
business process quality is performed according to the quality goals of the
business process. As discussed in Section 4.4.1.1, using a measurement goal-
driven approach that directly supports an organisation’s business goals and
objectives has been proven to be successful in assuring that the identified
metrics are relevant and are effectively utilised [127]. The work by Soffer
and Wand [157, 159] in evaluating process model validity based on the in-
tegration of goals into process models also enforces the applicability of a
goal-driven quality measurement for business processes.
The goal-driven measurement approach proposed for the QoBP frame-
work is based on several advanced requirements engineering techniques such
as softgoal modelling approaches in Requirements Engineering [150, 151,
152, 128], and Goal-Question-Metric (GQM) [147]. As described in Section
4.4.1.1, the GQM approach by [147] is a well known goal-driven measure-
ment method [148] which is used during the requirement evaluation of Re-
quirements Engineering. Softgoal modelling is adopted because it is more
appropriate for representing and reasoning about quality requirements [128]
and was introduced to cope with the abstract and informal nature of non-
functional requirements [130]. GQM is adopted because: (1) it is a goal-
driven approach that assures the measurement of the quality characteristics
of a business process are performed according to the quality goals of the
process; (2) it provides a structured approach in identifying measurement
attributes.
The adapted measurement approach, with respect to the QoBP frame-
work proposed in this study, results in three models: softgoal model, soft-
goal correlation model, and measurement model. These models are
described in the following sub-sections. Section 4.4.2 presents the softgoal
model which models the quality characteristics of quality model as a set of
softgoals. Section 4.4.3 presents the softgoal correlation model that models
the relationships between softgoals. Section 4.4.4 presents the measurement
model which represents how quality characteristics described in the form of
softgoals, are evaluated.
94 4 The Design Science Phase
4.4.2 QoBP Framework - Softgoal Model
This section presents the softgoal model of the QoBP framework. A soft-
goal model for a business process contains all the softgoals identified for all
the quality characteristics (four dimensions) identified for a process. As de-
scribed in Section 4.4.1, quality characteristics are often not clear-cut; they
are often subjective, implicit, context-specific and imprecise31. Therefore,
to evaluate quality characteristics, they must be further refined into a set
of softgoals.
To specify softgoals, this research adopts an approach which is similar to
goal modelling in GQM approach [147]. In a softgoal model, each softgoal
is specified by four attributes:
• Purpose - Specifies the purpose of the goal [147]. The purpose usually
includes key words verbs such as increase, reduce, improve, and make
which describes the type of target condition desired [161], [146].
• Quality characteristic - Specifies the quality characteristic that a soft-
goal is defined for. It is similar to the “issue” in the GQM approach[147],
with the difference being that the quality characteristic is known when
a softgoal is being specified.
• Object - Specifies the target object of the softgoal [147]. In the context
of this research, the target object that a softgoal is specified for is one of
the four dimensions of the business process: a function, an input/output,
a human resource, or a non-human resource.
• Triggering condition - Specifies the context in which the softgoal is
important. This attribute is introduced by this research to describe the
triggering condition for a softgoal.
A softgoal is specified based on the above attributes using a pattern like :
31 Refer to Section 4.4.1 for further details on subjectivity, implicity, context- specificity, andimpreciseness of quality characteristics.
4.4 95
“To + purpose + the + quality characteristic + of the + object
+ [if + triggering condition”].
For example: “To increase the time efficiency of the loan ap-
proval function if loan value is less than $500,000.”. The argu-
ments inside [] are optional as not every softgoal may have a triggering
condition associated with it.
Softgoals specified using the above pattern are comprehensive and easy to
understand. The next section presents the softgoal correlation model which
models the dependencies between softgoals.
4.4.3 QoBP Framework - Softgoal Correlation Model
The purpose of this section is to present the softgoal correlation model of
the QoBP framework. The purpose of this model is to identify the corre-
lations between the softgoals modelled in a softgoal model of a business
process. This correlation presents the relationships between a softgoal and
other softgoals of a softgoal model.
The relationships between goals (both hard goals and softgoals) have
been modelled in Requirements Engineering for a variety of reasons. The
modelling approach also varies as each approach satisfies a set of specific
needs. For instance, Goal Centric Traceability is an approach in which non-
functional requirements and their interdependencies are modelled as soft-
goals in a Softgoal Interdependency Graph (SIG) [150]. The interdependen-
cies modelled in a SIG are used to manage the effect of functional changes
upon the non-functional requirements in order to maintain the quality of
software throughout its operational lifetime. In SIG, interdependencies be-
tween two softgoals S1 and S2 represents how S1 contributes to S2. This
contribution can be positive, negative or in some cases no effect at all. For
example, in a SIG that is modelled for an inventory system, the softgoal
“store data in non-compressed format” has a positive contribution to the
softgoal “process file fast” while having a negative contribution to the soft-
goal “have a manageable space” [150]. Goal correlation has also been used in
Requirements Engineering to explore alternatives and evaluate them with
respect to business objectives during requirements analysis [142, 162]. In
96 4 The Design Science Phase
their work, goals are refined further to a set of sub-goals forming a goal hi-
erarchy. The correlations represents the influence between two goals which
is either positive or negative.
In this research softgoal correlations are used to conduct root cause anal-
ysis for quality issues of a business process. Section 4.5 describes in detail
how a softgoal that is not satisfied for an instance of a process may cause
a quality issue for that process. Section 4.5 also describes in detail how the
softgoal correlation model for a business process will be used to identify the
root causes of the quality issues during the quality improvement phase of
the quality-aware BPM life cycle32. This section describes how a softgoal
correlation model is created.
The softgoal correlations in the QoBP framework are modelled to present
the functions dependency based on the data flow and control flow. Therefore,
the correlations are positive in nature. A direct correlation is established by
the fact that softgoals for the output of functions match softgoals where
their outputs become inputs of downstream functions33. In principle, each
softgoal can be correlated to any other softgoal. Yet, there are some con-
straints. First, a softgoal g1 related to a function f1, i.e. g1 ∈ relevant(f1),
should only be correlated to another softgoal g2 of another function f2 if
there is a path f1 → f2 from f1 to f2. This condition builds on the basic
property of causality that a can only cause b if it proceeds b temporally34.
In the context of a process, this means that softgoals of a function f1 can
only have a positive impact on those softgoals that relate to a function f2
executed later. Second, the correlation relation between different softgoals
should be irreflexive35 and acyclic36. This guarantees that a softgoal does
not influence itself.
32 Quality-aware BPM life cycle was described in Section 4.2 of this chapter.33 Refer to Section 4.4.6.5 for an illustration on how a softgoal correlation model can be created.34 For example, process A consists of three functions f1, f2, and f3. Softgoals of the function f1
can have a positive impact on the softgoals of both f2 and f3 as these functions execute afterf1. Softgoals of the function f3 therefore can not have a positive impact on neither f1 nor f2.
35 A relation in a set is irreflexive provided that no element is related to itself [163].36 A relation is acyclic if there is no loop linking [164].
4.4 97
The next section presents the measurement model which supplements
the softgoal model presented in Section 4.4.2 to support the evaluation of a
business process quality.
4.4.4 QoBP Framework - Measurement Model
This section presents the measurement model of the QoBP framework. For a
business process, this model contains the measurable attributes (referred to
as quality metrics). These quality metrics are identified to evaluate the qual-
ity characteristics of the business process modelled in the form of softgoals.
As described in Section 4.4.1, the measurement of the quality characteris-
tics is necessary to support the full life cycle of a quality-aware business
process37. In the QoBP framework, the quality characteristics of a process
are further refined to a set of softgoals modelled in a softgoal model (Section
4.4.2).
In general, a softgoal is similar to a hard goal38 except that the eval-
uation criteria for whether a softgoal is achieved are not often clear-cut
[128]39. In comparison to (hard) goals, softgoals are often subjective and
context-sensitive [160]. Softgoals therefore involve subjectivity because of a
lack of objective achievement criteria, and the responsibility for evaluating
their achievement falls on stakeholders. Refer to an earlier example (loan
application process presented in Section 4.4.2), for the softgoal “to increase
the timeliness of the loan approval function” . It is responsibility of the
goal originator to determine what timeliness means to this function. The
constraints that define the timeliness of the loan approval function such as
duration of the loan approval need to be specified. After such attributes (e.g.
duration of the loan approval) are specified, the acceptable value (or range
value) that is in accordance to the corresponding measuring scale40 needs
to be defined for each attribute. For example, for the duration of the loan
37 Refer to Section 4.4.1 for furthers details on why the measurement of the quality character-istics is essential (four reasons were discussed).
38 The achievement criteria for a (hard) goal is sharply defined (e.g. buy a computer) [160].39 In Software Engineering discipline, hard goals (usually just referred as goals) are used to define
the functional requirements of the system, while softgoals are used to define non-functional(quality) requirements.
40 Similar to the standard measuring scale recommended by ISO/IEC [105, 106, 107] which are:nominal scale, ordinal scale, ratio scale, and interval scale. These scales are described in detailin Section 4.4.1.1.
98 4 The Design Science Phase
approval attribute a range (ratio scale) can be used (e.g. duration of the loan
approval <2 days). Respectively, in the QoBP framework, the softgoals of a
business process are further refined to a set of measurable attributes referred
to as quality metrics. Quality metrics for softgoals of a business process and
their associated threshold values are modelled in a measurement model.
This research adopts an approach similar to the GQM [147] approach in
refining softgoals to a set of quality metrics. As described in Section 4.4.1.2,
GQM [147] provides a structured approach in identifying the quality met-
rics for a business process.
To define quality metrics, a softgoal is refined into a set of questions and
then each question is refined into a set of quality metrics. Basili et al [147]
recommend three groups of questions. Based on the structure of a softgoal
in the QoBP framework (purpose, quality characteristic, object, and trig-
gering condition), three groups of questions include41:
1. Questions regarding how to characterise the object (function, input/output,
resource, and human resource) with respect to the softgoals.
2. Questions regarding how to characterise the attributes of the object
(function, input/output, resource, and human resource) that are rele-
vant to the softgoal.
3. Questions regarding how to evaluate the characteristics of the object
(function, input/output, resource, and human resource) that are relevant
to the softgoal.
A set of appropriate quality metrics needs to be associated with each
question once all the questions for the softgoal are defined. The quality
metrics are derived through a question-answer mechanism, by asking what
quality metrics should be defined to answer those questions. Following on
with the running example (the loan application process), one question could
be: “how long does a loan approval take now?”. The loan approval duration
41 Section 4.4.6.6 illustrates these questions and their refined quality metrics through a workingexample.
4.4 99
Softgoal Model
Softgoal 1 Softgoal 2
Question
Quality Metric
QuestionQuestionQuestion
Quality Metric
Quality Metric
Quality Metric
Quality Metric
Quality Metric
Measurement Model
Fig. 4.7. GQM in the QoBP Framework
is an appropriate quality metric to provide an answer for this question. This
repetitive question-answer approach assists the stakeholder(s) to refine soft-
goals, that are often highly subjective, to a set of measurable quality metrics.
Once quality metrics are identified, an acceptable value (or range value) will
be defined for each metric. Figure 4.7 depicts how this adaptation of the
GQM approach links a softgoal model to a measurement model in the QoBP
framework.
These newly introduced quality related models (such as the quality
model, the softgoal model, the softgoal correlation model, and the mea-
surement model) are important building blocks of a quality-aware business
process model. The next section presents the QoBP metamodel which pro-
vides an extension to the EPC notation in order to embed these quality
related elements into a business process model.
4.4.5 Quality-aware EPC
The section presents the QoBP Metamodel. The QoBP metamodel pro-
vides an extension to the EPC notation to embed the quality related mod-
els. These models introduced as part of the QoBP framework, support the
quality definition phase of the quality-aware BPM life cycle to produce a
100 4 The Design Science Phase
quality aware business process model. None of the popular business process
modelling notation [165] provides support for embedding these quality re-
lated models. The traditional strategy for process design starts by reflecting
current practices in a so-called as-is process model. This is followed by the
design of an improved to-be process model [166]. These models can only
capture the procedural dimension of a process and provide limited insights
into related quality factors. Consequently, the gap between as-is and to-be
is poorly supported by popular process modelling notations such as EPC,
BPMN, and Petri nets (see Appendix A.1). These process models are un-
able to facilitate quality analysis in the established tradition of the quality
management community. In this section we propose an extension to the
EPC metamodel to fill this gap. Prior to presenting the QoBP metamodel,
a short description on different levels of abstraction in business process
modelling such as business process instance, business process model, and
business process metamodel is presented below to justify why the QoBP
metamodel plays an essential role in the QoBP framework.
A business process model is an abstract description of a business process
that represents selected process elements that are important to the purpose
of the model [44]. A business process model is simply an artefact consisting
of a set of activities and the flows between them. Business process mod-
els are the main artefact for implementing business processes [4]. Therefore
they play an important role in continuous process improvement, quality
management, knowledge management, and software implementation within
an organisation [167].
Business process modelling is simply the process of creating an abstrac-
tion of a business process called a business process model. In order to capture
the complexity in business process management, Weske [4] introduced a hor-
izontal abstraction that is concerned with the separation of modelling levels,
from instance level to model level and metamodel level. Figure 4.8 depicts
the different levels of abstractions and their relationships. The instance level
(M0: Instance) represents the concrete entities (executed activities, concrete
data values, resources and persons) that are involved in business processes.
A business process instance is an instantiated version of a business process
4.4 101
M2: Metamodel
M1: Model
M0: Instance
Notation
Instance-of
Instance-of
describes
describes
expresses
Fig. 4.8. Horizontal Levels of Abstractions of a Business Process [4]
model. The identified and classified set of similar entities at instance level
are presented at the model level (M1: Model). For example a business pro-
cess model represent a set of similar business process instances. The models
then are expressed in metamodels (M2: Metamodel) using notations asso-
ciated with the metamodels. The notation associated with a metamodel is
used to express the concepts of that particular metamodel. For example the
Event-Driven Process Chain (EPC) notation associates graphical symbols
(e.g. rectangle) with the metamodel elements (e.g. functions). The meta-
model’s definition in [4] is similar to the definition of the metamodel in
conceptual modelling which is “a metamodel is a model of a data model
such as an ER42 model” [169].
As the QoBP metamodel is an extension to the EPC metamodel, it is
beneficial to describe the EPC metamodel prior to describing the QoBP
metamodel. The EPC metamodel and its formal syntax are presented in
the following section.
42 ER model is a conceptual data model that views the real world as entities and relationships[168].
102 4 The Design Science Phase
4.4.5.1 EPC Metamodel
The purpose of this section is to present the EPC metamodel and its for-
mal syntax. Figure 4.9 presents the EPC metamodel which is constructed
as an UML43 class diagram. The diagram presents the essential elements
of an EPC, i.e. control flow elements including functions, events, and con-
nectors which are linked by control flow arcs. Furthermore, each function
can be described regarding its input and output as well as its resource (hu-
man & non-human resource) requirements. Functions capture activities of
a process, while events describe pre-conditions and post-conditions of func-
tions (events trigger functions). Connectors are used to model the process
logic. There are three kinds of connector types including AND44, OR45, and
XOR46. Connectors have either multiple incoming and one outgoing arc
(join connectors) or one incoming and multiple outgoing arcs (split connec-
tors). Control flow arcs are used to link these elements.
A simplified formal syntax of EPC [170]47 which includes resources and
input/output objects is presented below (Definition 1). :
Definition 1 - EPC An EPC is a tuple (E, F, C, t, A, R, I, O, r), where:
• E is a finite set of events,
• F is a finite set of functions,
• C is a finite set of logical connectors,
• t : C → {∧,×,∨} is a function which maps each connector onto a con-
nector type,
• A ⊆ (E × F ) ∪ (F × E) ∪ (E × C) ∪ (F × C) ∪ (C × F ) ∪ (C × C) is a
set of arcs,
43 The Unified Modeling Language (UML) is a standard language for specifying, visualising,constructing, and documenting the artifacts of software systems, as well as for business mod-eling and other non-software systems. Please refer to http://www.uml.org/ for further detailson UML.
44 AND-split activates all subsequent branches in concurrency, while the AND-join waits for allincoming branches to complete, then it propagates control to the subsequent EPC element.
45 The OR-split triggers one, two or up to all of multiple branches based on conditions, whilethe OR-join synchronizes all active incoming branches.
46 The XOR-split represents a choice between one of several alternative branches, while theXOR-join merges alternative branches.
47 The formal syntax by [170] is based on original EPC formal syntax by [125].
4.4 103
Resource Input Output
Function
Event Connector
Control Flow ElementControl Flow Arch**
Non-Control Flow Element
1
1..*
**
Non-human Resource Human Resource
Fig. 4.9. EPC Metamodel
• R is a finite set of resources,
• I is a finite set of inputs,
• O is a finite set of outputs, and
• r : {R∪I∪O} → F} is a mapping that assigns roles, inputs, and outputs
to functions.
The next section presents the QoBP metamodel proposed by this thesis.
The QoBP metamodel is an extension to the EPCmetamodel which includes
the quality related elements (such as quality characteristics, softgoals and
quality metrics) introduced by the QoBP framework.
4.4.5.2 QoBP Framework - QoBP Metamodel
The QoBP metamodel (shown in Figure 4.10) is an extension to the EPC
metamodel which builds on control flow based business process modeling.
The upper part of Figure 4.10 captures the essential elements of an EPC (as
shown in Figure 4.9). This part of the metamodel is classical process mod-
eling and can easily be replaced by respective elements of other modeling
languages such as BPMN or high-level Petri nets. The QoBP metamodel in-
troduces additional concepts to capture those entities relevant to the quality
104 4 The Design Science Phase
of a business process (in the lower part of Figure 4.10). The QoBP builds
on identifying softgoals for a function based on the quality characteristics
related to four quality dimensions of a business process (one softgoal per
quality characteristic). The relevance of a softgoal is bound to a triggering
condition that needs to be specified. The triggering condition determines
the context in which a softgoal is important. The achievement of a softgoal
is made measurable by relating it to a metric based on the goal-driven mea-
surement approach proposed in Section 4.4.1.2.
Resource Input Output
Function
Event Connector
Control Flow ElementControl Flow Arch* *
Non-Control Flow Element
1
1..*
* *
Softgoal-TriggeringCondition
-has 0..1
0..*
0..1-correlates to 0..*
Metric-FailureCondition
1
-is measured by0..*
Non-Human Resource Human Resource
Quality Characteristic -represented and reasoned by
0..1 0..1
Fig. 4.10. QoBP Metamodel as a UML class diagram
4.4 105
The formal syntax of the QoBP metamodel is presented below:
Definition 2 A QoBP is a tuple (E, F, C, t, A, R, I, O, r, Q, G, S,M),
where:
• E is a finite set of events,
• F is a finite set of functions,
• C is a finite set of logical connectors,
• t : C → {∧,×,∨} is a function which maps each connector onto a con-
nector type,
• A ⊆ (E × F ) ∪ (F × E) ∪ (E × C) ∪ (F × C) ∪ (C × F ) ∪ (C × C) is a
set of arcs,
• R is a finite set of resources,
• I is a finite set of inputs,
• O is a finite set of outputs, and
• r : {R∪I∪O} → F} is a mapping that assigns roles, inputs, and outputs
to functions.
• Q is a finite set of quality characteristics,
– applicable: {F,R, I, O} 7→ {0, 1} is a mapping that indicates whether
a quality characteristic is applicable for the respective class of entities;
• G is a finite set of softgoals,
– relevant: {F ∪ R ∪ I ∪ O} × Q 7→ PG is a mapping that assigns a
function, role, input, or output to one a softgoals of G that relates to
a quality characteristic q ∈ Q,
– S ⊆ G×G defines the correlation relationship between a pair of soft-
goals such that (g1, g2) ∈ S means that g1 has an influence on g2,
· A softgoal g1 related to a function f1, i.e. g1 ∈ relevant(f1), should
only be correlated to another softgoal g2 of another function f2 if
there is a path f1 → f2 from f1 to f2. This condition builds on
the basic property of causality that a can only cause b if it proceeds
b temporally. In the context of a process this means that softgoals
of a function f1 can only have a positive impact on those softgoals
that relate to a function f2 executed later.
106 4 The Design Science Phase
· The correlation relation between different softgoals should be ir-
reflexive and acyclic. This guarantees that a softgoal does not in-
fluence itself.
• M is a finite set of metrics.
– question: G 7→ PM is a mapping that assigns one or many metrics
to a softgoal;
The essential models of the QoBP framework were introduced in the ear-
lier sections of this chapter. This sub-section presented an extension to the
EPC metamodel (referred to as QoBP metamodel) that embeds all the nec-
essary elements of the QoBP models into the EPC metamodel. A business
process that is modelled based on the QoBP metamodel is a quality-aware
business process model.
The next section (Section 4.4.6) completes the QoBP framework by pre-
senting the QoBP methodology which provides a step-by-step procedure
of how to create a quality-aware business process model during the quality
definition phase of the quality-aware BPM life cycle. The QoBP methodol-
ogy is illustrated through a working example which is the case of a software
project process (Request for Proposal - RFP) that is used by Software House
(SH) for responding to tenders [126].
4.4.6 QoBP Framework - QoBP Methodology
The purpose of this section is to introduce the methodology provided by the
QoBP framework to create a quality-aware business process model during
the quality definition phase of the quality-aware BPM life cycle (see Fig-
ure 4.3). This methodology provides the step-by-step procedure required to
create a quality-aware business process model that is based on the QoBP
metamodel introduced in the previous section (Section 4.4.5.2). This sec-
tion illustrates how to create all the quality related models of the QoBP
framework described earlier sections necessary to produce a quality-aware
business process model.
It is always beneficial to illustrate a methodology through a working ex-
ample, so a case from the earlier works [97, 126] has been selected. This is
the case of a software project process referred to as Request for Proposal
4.4 107
(RFP) that is used by a Software House (SH) for responding to tenders.
The QoBP methodology proposed in this research includes six major
steps:
1. Analyse the business process
2. Create a business process model
3. Create a quality model
4. Create a softgoal model
5. Create a correlation model
6. Create a measurement model
Each of these steps is described in detail in the following sub-sections48.
Each step is also illustrated through an example which is based on the RFP
process of the Software House (SH).
4.4.6.1 Analyse the Business Process
The purpose of the first step is to analyse the business process. The organi-
sational structure, the business process goals, the business process environ-
ment, and the quality requirements of the business process will be analysed
during this step. Also, the functional and quality (non-functional) require-
ments of the process will be elicited, taking account of the organisation’s
strategy, goals and structure. The deliverable of this step will be a document
describing the functional and quality requirements of the business process
being analysed. Section 5.3.4.1.1 provides extra guidelines and templates
that are required to perform this step.
For example, the analysis of the RFP process revealed that the RFP pro-
cess is used by Software House (SH) for responding to tenders. The company
submitting the RFP is usually seeking the delivery of some software. The
process commences with the receipt, by a software house, of an RFP from
the client company. The RFP documents the high level requirements of
48 Section 5.3.4 which describe the protocol for conducting the action research as part of thisstudy to evaluate artifacts that are presented in this chapter provides extra guidelines, tem-plates and tools for performing each step.
108 4 The Design Science Phase
the system and asks that software houses respond by providing a proposed
solution, an estimate of the time and cost to complete the work and an in-
dicative project plan. The analysis also revealed the quality requirements of
the RFP process. It is crucial for SH to create a high quality RFP response
for their VIP clients to increase the chance of being awarded the work (to
win the tender). The indicative project plan must be based on an accurate
effort and cost estimate. The RFP response should be precise and easy to
understand and should have all the requested information.
Having analysed the business process, the next step of the QoBP method-
ology is to create a business process model which is based on the functional
requirements defined during this step. The next section presents how to
create a business process model.
4.4.6.2 Create the Business Process Model
The purpose of this step is to model a business process using a business pro-
cess modelling notation. The quality framework proposed in this research
is not bound to any specific business process modelling methodology or no-
tation. Therefore, a business process, at this step can be modelled using
any methodology and notation. Dumas, van der Aalst and ter Hofstede [93]
describe several business process modelling methodologies using different
notations such as EPC, UML, and Petri nets in their book . Similar guide-
lines are also provided in [166, 4] that can be used as an alternative during
this step. The output from this step is a business process model that defines
business functions, their control-flow relationships, as well as resources, and
the inputs / the outputs that are assigned to each function. Section 5.3.4.1.2
provides extra guidelines that are required to perform this step.
Figure 4.11 presents an example outcome from this step which is the
RFP business process model modelled using the EPC49 modelling notation.
The RFP documents the high level requirements of the system to be devel-
oped and typically asks SH to respond by providing a proposed solution, an
estimate of the time and cost to complete the work and an indicative project
plan. After receiving the RFP, the marketing/sales department reviews the
49 Refer to Appendix A.1 for further details on EPC. For formal details of EPCs refer to [171].
4.4 109
RFP is Received
Conduct Preliminary
Review
Marketing/Sales Department
RFP
Review Requirement
RFP
Business Department
Formulate a Solution
Review the Solution
Estimate
Formulate RFP Reponse
Propose Indicative
Project Plan
Send RFP Response
Response is Sent
Development Department
Development Department
Business Department
Development Department
Project Management
Group
Marketing/Sales Department
RFP
Solution
Solution RFP
Solution RFP
Estimate
Solution RFP Estimate
Solution RFP Estimate
RFP Response
RFP Response Send RFP
Withdrawal Response
XOR
Project Plan
Project Plan
Withdrawal Response
RFP
XOR
Fig. 4.11. Request for proposals process of the software house
110 4 The Design Science Phase
RFP to determine the parameters of the response (Conduct Preliminary
Review). This review provides first insight regarding the potential profit
from the project and the strategic interest of the client. Depending on this
information a decision is made (XOR-split): if the business is likely to be
unattractive, SH will Send RFP Withdrawal Response, otherwise further
steps to complete the RFP response are undertaken. This series of steps
starts with a review of the requirements by the business department who
forwards the RFP to the development department. The Development de-
partment formulates a technical solution based on the RFP. This solution is
reviewed before it is used as a base for estimation of cost and effort. These
estimates and the solution are then considered for proposing an indicative
project plan worked out by the project management team. In particular,
the project schedule, project cost and the project team is outlined. This
plan along with the estimation and the solution concept is input for the
business department to formulate the RFP response. The marketing/sales
department finally sends this RFP response to the potential client.
Having modelled the business process, the next step of the QoBP
methodology is to create a quality model for the business process model.
4.4.6.3 Create a Quality Model
The objectives of this step is to create a quality model for a business pro-
cess which is based on the quality requirements defined during the first step
(see Section 4.4.6.1). The quality model was described in Section 4.3. The
aim is to identify the potential quality characteristics for all four dimen-
sions (function, input & output, human resource and non-human resource)
of a business process. It is crucial to ensure the quality characteristics being
selected for the process are aligned with the quality requirements defined
during the first step.
The quality requirements defined for the process need to be mapped to
the process functions. This mapping associates each quality requirement to
one or more functions. This critical task heavily relies on the assessment
and the expertise of the domain experts.
4.4 111
To create a quality model for a process, the following steps are required
for each function of the process50:
1. Select the relevant quality characteristics identified for the function di-
mension (Section 4.3.2.1). For example, the main quality characteristic
for the function estimate is identified as accuracy.
2. Select the relevant quality characteristics identified for the input & out-
put dimension (Section 4.3.2.2). For example, the main quality char-
acteristic for the output project estimate from the function estimate is
identified as accuracy.
3. Select the relevant quality characteristics identified for the human re-
source dimension (Section 4.3.2.3). For example, the main quality char-
acteristic for the developer in charge of estimating is identified as expe-
rience.
4. Select the relevant quality characteristics identified for the non-human
resource dimension (Section 4.3.2.4). For example, the main quality char-
acteristic of the software tool that is used to calculate the project esti-
mate for the function estimate is identified as effectiveness.
The result of this step is a set of generic quality characteristics for all
four quality dimensions of a business process. Section 5.3.4.1.3 provides
extra guidelines, and templates that are required to perform this step. The
next section presents the next step of the QoBP methodology which is how
to create a softgoal model.
4.4.6.4 Create a Softgoal Model
The objective of this step is to create a softgoal model for the quality char-
acteristics modelled in the previous step. The softgoal model was described
in Section 4.4.2. During this step, each quality characteristic is refined to
50 The quality requirements associated with each function guides the selection of quality char-acteristics during these steps.
112 4 The Design Science Phase
a meaningful softgoal. Each softgoal needs to be specified using the recom-
mended pattern (see Section 4.4.2) which contains all the attributes (pur-
pose, quality characteristic, object, and triggering condition) required to
represent a softgoal. Section 5.3.4.1.4 provides extra guidelines, and tem-
plates that can be used to perform this step.
For example, the softgoals for the quality characteristics identified for
the function estimate in the previous section are:
1. Function quality characteristic: accuracy
• Softgoal: To increase the accuracy of the function estimate if the value
is over $150,000
2. Output quality characteristic: accuracy
• Softgoal: To increase the accuracy of the output estimate if the esti-
mation time is greater than 6 months
3. Human resource quality characteristic: experience
• Softgoal: To increase the experience of the software engineer if the job
requires new technology
4. Non-human resource: effectiveness
• Softgoal: To increase the effectiveness of the estimation tool if the job
is rated as complex
The result of this step is a softgoal model for a business process. Next
section presents the next step of the QoBP methodology which is how to
create a softgoal correlation model.
4.4.6.5 Create a Correlation Model
The purpose of this step is to create a softgoal correlation model for the
softgoals specified in the softgoal model of a business process. As described
in Section 4.4.6.5, the correlation presents the relationships between one
softgoal and other softgoals of the softgoal model defined in the previous
step. A correlation is established by the fact that softgoals for the output of
4.4 113
functions match softgoals where their outputs become inputs of downstream
functions. The softgoal correlations are positive in nature. The softgoal cor-
relation model was described in Section 4.4.3. A softgoal correlation model
is created by performing the following steps:
1. Start with the last function in the business process.
2. For each of the data inputs for this function, identify the functions ear-
lier in the process where this data was output.
3. Create a correlation between the softgoals of the function and the soft-
goals of those earlier functions.
4. Repeat steps 2 and 3 for each of the previous functions in the process.
The result of this step is a softgoal correlation model for a business pro-
cess. Section 5.3.4.1.5 provides extra guidelines, and templates that may be
used to perform this step.
Figure 4.12 depicts the softgoal correlation model for three functions of
the RFP process: estimate, prepare indicative project plan, and formulate
RFP response. Two correlations are established by the fact that softgoals
for the output of functions match softgoals where their outputs become in-
puts of downstream functions. The first correlation is between softgoal 11
and softgoal 6. The second correlation is between softgoal 6 and softgoal 1.
Each correlation is represented as a wide arrow (the left side of Figure 4.12).
The dotted narrow arrows in the right side of Figure 4.12 represent the link
between inputs and outputs of these three functions that are the cause for
the correlations.
The following section presents the next step of the QoBP methodology
which is to create a measurement model.
4.4.6.6 Create a Measurement Model
The purpose of this step is to create a measurement model for the softgoals
specified in the softgoal model of a business process. The measurement
114 4 The Design Science Phase
Softgoal 8: To increase the accuracy of the “PM Tool”
Softgoal 6: To increase the accuracy of function “propose indicative project
plan” Softgoal 9: To increase accuracy of the “Project Plan”
Non-human Resource: PM Tool
Output: Project Plan
Softgoal 10: To increase the experience of the “Project Managre”
Human Resource: Project Manager
Softgoal 14: To increase the accuracy of “MS Word”
Softgoal 11: To increase the accuracy of the “formulate RFP response”
Softgoal 15: To increase accuracy of “RFP Response”
Non-human Resource: MS Word
Function: Formulate RFP response
Output: RFP Response
Softgoal 16: To increase the experience of the “Project Manager”
Human Resource: Project Manager
Softgoal 3: To increase the accuracy of the “Estimation Tool”
Softgoal 1: To increase the accuracy of the function “Estimate”
Softgoal 4: To increase accuracy of Estimate
Non-human Resource: Estimation Tool
Function: Estimate
Output: Estimate
Softgoal 5: To increase the experience of the “Software Engineer”
Human Resource: Software Engineer
Softgoal 2: To increase the accuracy of the “RFP Business Requirement”
Input: RFP Business Requirements
Softgoal 7: To increase the accuracy of the “Estimate”
Input: Estimate
Softgoal 12: To increase the accuracy of the “Project Plan”
Input: Project Plan
Softgoal 13: To increase the accuracy of the “Estimate”
Input: Estimate
Second correlations
First correlations
Function: Propose indicative project plan
Fig. 4.12. An Example for Softgoal Correlations Model
model was described in Section 4.4.4. This model contains the measurable
attributes (referred to as quality metrics) that are identified to evaluate the
quality characteristics of a business process that are modelled in the form
of softgoals.
As described in Section 4.4.4, this research adopts an approach similar
to the GQM [147] approach in refining softgoals to a set of quality metrics.
During this step, each softgoal is refined into a set of questions and then
each question is refined into a set of quality metrics. For example, questions
for the softgoal51 defined for a Software Engineer who is a human resource
for the function estimate could be: what is the current experience of the
51 To increase the experience of the software engineer if the job requires new technology.
4.4 115
human resource for the function estimate? and is the current experience
of the human resource for the function estimate satisfactory?. The quality
metrics are derived through a question-answer mechanism, by asking what
quality metrics should be defined to answer those questions. For example
a metric for the above questions is the software engineer experience. Once
quality metrics are identified, an acceptable value (or range value) that is
with accordance with the corresponding measuring scale will be defined for
each metric (as described in Section 4.4.4). For example, the acceptable
value range for the above example is: the software engineer experience > 2
years.
The result of this step is a measurement model for the business process.
Section 5.3.4.1.6 provides extra guidelines, and templates that are required
to perform this step.
4.4.7 Summary of QoBP Framework Part II
The main purpose of this section was to present the additional artifacts
of the QoBP framework that were developed by this thesis to support
the quality definition phase of the quality-aware BPM life cycle. This sec-
tion presented how in the Quality of Business Process (QoBP) framework,
the quality model proposed in Section 4.3 is utilised to create a quality-
aware business process model. The goal-driven measurement approach in
the QoBP framework was presented in Section 4.4.1, as well as the justifi-
cation for choosing a goal-driven approach and a summary of the literature
review in the relevant areas. Three essential models of the QoBP frame-
work that support the goal-driven measurement approach adopted by this
research were presented in this order: Section 4.4.2 presented the softgoal
model that models the quality characteristics of the quality model as a set of
softgoals; Section 4.4.3 presented the softgoal correlation model that mod-
els the relationships between these softgoals; Section 4.4.4 introduced the
measurement model which presents how quality characteristics, that are de-
scribed in the form of softgoals are evaluated. The QoBP metamodel which
is an extension to the EPC notation to embed the QoBP framework models
into a business process model was presented in Section 4.4.5.2. The last
section (Section 4.4.6) was dedicated to introduce the QoBP methodology
116 4 The Design Science Phase
which provides a step-by-step procedure to create a quality-aware business
process model.
The next section presents the artifact that is developed to support the
quality improvement phase of the quality-aware BPM life cycle. The next
section introduces a novel root cause analysis approach that is referred to
as Process Root Cause Analysis (PRCA) technique.
4.5 Quality Improvement - PRCA 117
4.5 Quality Improvement - PRCA
The chapter presents the artifact developed by this thesis to support the
quality improvement phase of the quality-aware BPM life cycle52 (high-
lighted orange in figure 4.13). The previous two sections presented the pro-
posed artifacts to support the quality definition phase of the quality-aware
BPM life cycle. As described in Section 1.1.2, the quality implementation
and quality control phases of the quality-aware BPM life cycle are out of
scope of this thesis. In this study, quality improvement at this stage of the
business process life cycle, is only concerned with the root cause analysis
(RCA) of the cases where quality requirements were not met (referred to as
quality issues in this research). This section introduces the Process Root
Cause Analysis (PRCA) technique to support the root cause analysis
of the quality issues, the cases where quality requirements were not met.
Analysis
Design
Implementation
Enactment
Monitoring
Evaluation
Business Process Requirements & Quality Requirements
Quality Aware Process Model
Implemented Quality Aware ProcessProcess & Quality Metrics
Measures for Improvements
Measurements
Process & Quality Metrics
Quality Improvement
Quality Definition
Quality Implementation
Quality Control
Fig. 4.13. Quality Improvement Phase
Root cause analysis is a problem-solving technique in a variety of quality-
centered management approaches such as Six Sigma, Lean Six Sigma, and
Total Quality Management53. For example, in Six Sigma, defects are avoided
through the elimination of the causes of quality or process related problems
52 Refer to Section 4.2 for further details on the Quality-aware BPM life cycle.53 Refer to Section 2.3.2.
118 4 The Design Science Phase
[73].
During the quality improvement phase of the quality-aware BPM life cy-
cle, the quality of enacted business process instances are evaluated in order
to identify improvement opportunities within the process. The evaluation
on its own only assists with the identification of the cases where the quality
of the business process instances have not met the original quality require-
ments of the business process (referred to as quality issues). These quality
issues may lead to improvement opportunities if their root causes are iden-
tified. Large companies often document their business operations in several
thousand process models [172], and some industries are even obliged to do
so to comply with quality regulations. While these models could be a good
starting point for investigating and analysing causes of problems, it has been
observed that existing business process models provide little assistance for
such an exercise [173], because process modelling languages do not include
the relevant pieces of information nor methodological guidance provided for
gathering that information.
The QoBP framework proposed in the previous chapter addresses the
first issue by introducing quality-aware business process models that cap-
ture the relevant quality elements required for investigating and analysing
the root causes of quality issues. This chapter proposes the Process Root
Cause Analysis (PRCA) technique which provides a structured approach
and methodological guidance to conduct root cause analysis on business
processes.
In the context of this study, root cause analysis is used as a reactive
approach54 [174] to uncover the root causes of the quality issues that have
already occurred. By identifying the root causes of the quality issues in a
business process and rectifying these issues, then the quality of subsequent
enactments of the business process will be improved. Indeed, combining
business process models and root cause analysis has the potential of reveal-
ing problems in an organisation in a systematic way and relies less on the
54 A root cause analysis approach is proactive when it is used to prevent future issues fromoccurring [174].
4.5 Quality Improvement - PRCA 119
intuition of those involved in the analysis.
Section 4.5.1 presents a brief background on the root cause analysis tech-
niques and frameworks in other disciplines as well as a set of desirable
criteria for a root cause analysis technique. A more detailed description
of the root cause analysis techniques and frameworks in other disciplines
is provided in Appendix A.2. The Process Root Cause Analysis (PRCA)
technique is presented in Section 4.5.2. Section 4.5.2.1 provides a working
example for the PRCA technique. Section 4.5.2.2 presents a brief reflection
on the PRCA technique and how it adheres to the criteria listed in Section
4.5.1. Section 4.5.3 concludes this section by providing a short summary.
4.5.1 A Background on Root Cause Analysis
The purpose of this section is to provide a brief background on root cause
analysis in other disciplines. Root cause analysis is a problem-solving tech-
nique in a variety of quality-centered management approaches such as Six
Sigma, Lean Six Sigma, and Total Quality Management (TQM)55. The main
assumption is that an issue can only be solved by addressing the underlying
cause of the problem. Root cause analysis has been conducted in indus-
try using a variety of techniques [74]. The current practices mainly build
on brain-storming and semi-formal techniques [175]. Several approaches to
root cause analysis have been proposed in different industries, among others
so-called Ishikawa diagrams, or fishbone diagrams [176], Events and Causal
Factors Chart [177], Fault Tree Analysis [178] and others. After a thorough
review of the different root cause analysis techniques and frameworks used
in other disciplines56, it is apparent that most of these techniques lack a
systematic and structured approach that is suitable for root cause analysis
of quality issues of a business process instance.
This thesis proposes a root cause analysis technique that is suitable for
business processes. The root cause analysis technique proposed by this re-
search adheres to a set of criteria that are derived from both the weaknesses
and the strengths of the root cause analysis techniques in other disciplines.
55 Refer to Section 2.3.2 for further details on Six Sigma, Lean Six Sigma and TQM.56 Refer to Appendix A.2 for an overview of the root cause analysis techniques and frameworks
in other disciplines.
120 4 The Design Science Phase
All these criteria are derived by reviewing the root cause analysis tech-
niques in other disciplines, as well as their success stories and limitations.
The derived criteria include:
• Comprehensiveness : the framework should provide the investigator
the ability to identify the sequence of all events leading to a cause of
an issue. This criteria stems from the main requirement for a root cause
analysis technique which is to provide the ability to determine what hap-
pened and when that happened [177, 179].
• Context-awareness: the framework should provide investigators the
appropriate information (such as the context in which the issue has oc-
curred) that are required to conduct corrective actions. This criteria is
based on the need to be able to validate the conditions in which an issue
has occurred [179] and to distinguish between contextual, contributory
factors and the root causes of an incident [180].
• Systematic: the framework should provide a systematic methodology
that provides a consistent step-by-step approach to conduct the investi-
gation. This criteria ensures that one of the main characteristics of a root
cause analysis technique, which is to provide a structured [180] and con-
sistent [52] approach in investigating the root cause of an incident, is met.
• Easy to use : the framework should be easy to use. This criteria en-
sures that a root cause analysis technique is easy to use to conduct the
investigation, as the complexity of root cause analysis techniques is a
well known limiting factor for using the techniques [181].
The criteria listed above are used as a set of guidelines for the root cause
analysis technique, proposed by this thesis. This criteria will also be used
to evaluate the proposed root cause analysis technique during the action
research phase of this research57.
The next section presents the root cause analysis techniques proposed
by this thesis which is referred to as Process Root Cause Analysis (PRCA).
57 Refer to Section 5.3.5 for further information on how this criteria is used for evaluation.
4.5 121
4.5.2 Process Root Cause Analysis (PRCA) Technique
The main purpose of this section is to introduce the Process Root Cause
Analysis (PRCA) technique which is the artifact developed to support the
quality improvement phase of the quality-aware BPM life cycle. As men-
tioned earlier in this section, the quality improvement at this stage of the
business process life cycle, is concerned with the root cause analysis (RCA)
of the quality issues (the cases where quality requirements were not met).
This section presents a novel technique for conducting root cause analysis
of quality issues in quality-aware business processes (the business processes
that are modelled using the QoBP framework proposed in the previous
sections). The QoBP framework described in Sections 4.3 and 4.4 share the
analytical focus of root cause analysis (that has been criticised as being semi-
formal [175]) with the rigor of established concepts from requirements en-
gineering such as quality models, softgoal models, the goal-question-metric
approach, and softgoal correlations. PRCA provides a systematic step-by-
step procedure to analysts who aim to identify root causes of a quality issue.
The models58 that were introduced as part of the QoBP framework to
create a quality-aware business process model provide the necessary ele-
ments required to conduct root cause analysis. This section simply presents
a technique (referred to as PRCA) on how to use these elements to conduct
root cause analysis on quality issues. As mentioned at the beginning of this
chapter, a quality issue with respect to a business process is the case where
the defined quality requirements of the process are not met. Hence, there is
a relationship between a quality requirement and a quality issue. To make
this relationship more concrete, a reflection on how a quality requirement
is modelled in the QoBP framework is defined. As described in Section 4.4,
the quality requirements of a business process are modelled in the form of
quality characteristics for all four dimensions of the business process (func-
tion, input & output, human resource, and non-human resource). It was also
described (in Section 4.4.1) that the measurement of quality characteristics
is necessary to support the the full life cycle of a quality-aware business
process. In Section 4.4.2 it was discussed how quality characteristics need
58 The quality model (see Section 4.4), the softgoal model (see Section 4.4.2), the softgoalcorrelation model (see Section 4.4.3), and the measurement model (see Section 4.4.4).
122 4 The Design Science Phase
to be further refined to a set of softgoals in order to be evaluated and rea-
soned about59. As softgoals may involve subjectivity because of a lack of
objective achievement criteria, they need to be further refined to a set of
quality metrics. For each quality metric an acceptable value (or value range)
is selected that is used during softgoal evaluation.
Based on the above background, a quality issue is triggered if a softgoal
is not achieved. Therefore a quality issue, raised during the execution of a
function of a business process (at the process instance level), is linked to a
softgoal in the softgoal model part of the QoBP metamodel.
Resource Input Output
Function
Event Connector
Control Flow ElementControl Flow Arch* *
Non-Control Flow Element
1
1..*
* *
-TriggeringConditionSoftgoal
-represented and reasoned by
0..1 0..*
-has 0..1
0..*
0..1
-correlates to 0..*1
-is measured by0..*
Function Execution
Value
-raises1
0..*
-is caused1
0..*
Process Instance
Process Type
Non-Human Resource Human Resource
Quality CharacteristicQuality Issue
-FailureConditionQuality Metric
E.g. “loan approval” E.g. “loan approval for MS Heravizadeh”
E.g. “to increase the time efficiency of the
loan approval function”
E.g. “time efficiency requirement is not met”
E.g. “6 days ”
E.g. “duration of loan approval”
E.g. “loan value < $200,000”
E.g. “loan application process”
E.g. “loan application for values of $100,000 for MS Heravizadeh ”
Fig. 4.14. QoBP Metamodel - PRCA as a UML class diagram
Figure 4.14 illustrates how quality issues at a process instance level are
linked to the softgoals at the metamodel level. The diagram is divided into
two panels, the QoBP metamodel (from Figure 4.10) is presented in the
left panel, while elements related to the process instance are presented in
the right panel. As shown in the right panel of the Figure 4.14, quality
issues (“time efficiency requirement is not met”) relate to the execution
59 Quality characteristics are not often clear-cut; they are subjective, implicit, context-specificand imprecise. Therefore, to evaluate quality characteristics, they are required to be furtherrefined to a set of softgoals.
4.5 123
of a function in the process (Function Execution (“loan approval for MS
Heravizadeh”) and the way the function is conducted (described by values
(“6 days”) related to a metric (“duration of loan approval”). The verti-
cal line that connects a quality issue (“time efficiency requirement is not
met”) in the right panel of Figure 4.14 to a softgoal (E.g. “to increase time
efficiency of the loan approval function”) in the left panel presents the re-
lationship between a quality issue and a softgoal. This relationship implies
that a quality issue is raised for a function execution when a softgoal is
not satisfied. Softgoal satisfaction is determined by the value at the process
instance level (the right panel of Figure 4.14) for the metric that measures
the softgoal satisfaction. If the value of the quality metric in a particular
process instance meets the failure condition, this signals the occurrence of a
quality issue related to the execution of a singular function. The relevance
of a softgoal for a process instance is bound to a triggering condition (“loan
value of $200,000”) that is specified (e.g. time efficiency matters for loans
with values of less than $200,000). As shown in Figure 4.14, a quality issue
is raised at the process instance level, i.e. for a particular case like “loan
application for a value of $100,000 for Ms Heravizadeh”.
Having illustrated what a quality issue is with respect to a quality-aware
business process and how it is raised at a process instance level, the rest of
this section describes the PRCA technique. As mentioned at the beginning
of this section, the PRCA technique proposed by this research provides a
step-by-step procedure to identify the root causes of a quality issue for an
instance of a process. In order to trace a quality issue back to its root cause
for an instance of a business process, the correlations between softgoals that
are modelled in a softgoal correlation model for the process are used. The
PRCA technique that is proposed by this thesis to identify the root cause
of a quality issues for a business process instance consists of the following
steps:
1. In the softgoal correlation model, find the softgoal that is linked to the
quality issue ;
2. Trace the softgoal through the softgoal correlation model;
124 4 The Design Science Phase
3. Evaluate the traced softgoal and record the results60;
4. Repeat Step 2 and 3 until no more softgoals are traced;
5. Review the results from the evaluation of the traced softgoals;
6. Identify the last softgoal being traced which is not satisfied, i.e. it meets
the failure condition for a metric;
7. Find the quality issue that is linked to the last softgoal that was identi-
fied in the previous step. This quality issue is the root quality issue;
8. Find the quality metrics which contributed to the failure of the root
quality issue. These quality metrics are the root causes of the investigated
quality issue.
The next sub-section illustrates the PRCA technique using as an example
the RFP case that was introduced in Section 4.4.6.
4.5.2.1 An Illustration of the PRCA Technique
The main purpose of this section is to illustrate the PRCA approach through
a working example. In the Request for Proposal (RFP) process , SH has re-
cently won a major project using the RFP process. After three months SH
management have realized that the deliverables of the project cannot be
completed at the estimated cost. As a result the project is likely to generate
a loss. In order to prevent such losses in the future, SH investigates the root
causes for the flawed calculation. The RFP model offers SH management
an initial overview of the process,but it does not directly reveal problems
with its execution. To trace back the root causes of the prospective project
loss, SH wants to utilize a systematic approach.
Having created all the relevant models of the QoBP framework for the
RFP process, the software house SH initiates a root cause analysis for the
RFP process instance which is related to the loss making project using
60 Softgoal satisfaction is determined by the value at the process instance level (the right panelof Figure 4.14) for the metric that measures the softgoal satisfaction.
4.5 125
Softgoal 8: To increase the accuracy of the “PM Tool”
Softgoal 6: To increase the accuracy of function “propose indicative project
plan” Softgoal 9: To increase accuracy of the “Project Plan”
Non-human Resource: PM Tool
Function: Propose indicative project plan
Output: Project Plan
Softgoal 10: To increase the experience of the “Project Managre”
Human Resource: Project Manager
Softgoal 14: To increase the accuracy of “MS Word”
Softgoal 11: To increase the accuracy of the “formulate RFP response”
Softgoal 15: To increase accuracy of “RFP Response”
Non-human Resource: MS Word
Function: Formulate RFP response
Output: RFP Response
Softgoal 16: To increase the experience of the “Project Manager”
Human Resource: Project Manager
Softgoal 3: To increase the accuracy of the “Estimation Tool”
Softgoal 1: To increase the accuracy of the function “Estimate”
Softgoal 4: To increase accuracy of Estimate
Non-human Resource: Estimation Tool
Function: Estimate
Output: Estimate
Softgoal 5: To increase the experience of the “Software Engineer”
Human Resource: Software Engineer
Softgoal 2: To increase the accuracy of the “RFP Business Requirement”
Input: RFP Business Requirements
Softgoal 7: To increase the accuracy of the “Estimate”
Input: Estimate
Softgoal 12: To increase the accuracy of the “Project Plan”
Input: Project Plan
Softgoal 13: To increase the accuracy of the “Estimate”
Input: Estimate
Second correlations
First correlations
Fig. 4.15. An Example for Softgoal Correlations Model
the PRCA technique. As the correlation model presented in Section 4.4.6.5
is used in this example, Figure 4.12 is repeated in this section (see Fig-
ure 4.15) for the ease of reference. Following the step-by-step procedure
outlined above, the softgoal that is linked to the quality issue is identified61
as softgoal 11 (“to increase the accuracy of the ‘formulate RFP response’
function”). Tracing softgoal 11 through the softgoal correlation model leads
to the correlated softgoal62 which is softgoal 6 (“to increase the accuracy
of the ’prepare project’ function”). Softgoal 6 is evaluated and the results
are recorded63. Softgoal 6 is then traced64 to softgoal 1 (“to increase ac-
61 Step 1 of the PRCA technique.62 Step 2 of the PRCA technique.63 Step 3 of the PRCA technique.64 Repeat of Step 2 of the PRCA technique.
126 4 The Design Science Phase
curacy of the ’estimate’ function”). Softgoal 1 is evaluated and the results
are recorded65. After reviewing the results from the evaluation of the traced
softgoals66, it was discovered that softgoal 1 was the last softgoal that was
not satisfied67, and this leads to the root quality issue which is “the accuracy
of the ‘estimate’ function is not met”. Further investigation on the quality
metrics contributing to the quality issue68 reveales that the the software
engineer experience that is a defined quality metric to evaluate the human
resource softgoal (softgoal 3 ) did not meet the threshold value which is “>
2 years” leading to identification of the root cause of the original quality
issue. It was discovered that as the software engineer in charge of the esti-
mation was not experienced he failed to include a major cost component in
the final estimate. By utilising the PRCA technique, SH management was
able to determine the root cause of the problem which was related to an
inexperienced software engineer in charge of the estimation for that specific
RFP. To prevent the same problem from occurring (to improve the quality
of future enactments), SH management can either insure an experienced
software engineer is allocated to perform the estimation or ensure the es-
timate produced by an inexperienced resource is reviewed and validated
before being incorporated into the project plan.
Having illustrated the PRCA technique through an example, the next
section presents a brief reflection on this technique and how it adheres to
the criteria listed in Section 4.5.1.
4.5.2.2 PRCA Technique - A Brief Reflection
The example above illustrated how the PRCA technique can be used to iden-
tify the root cause of a problem in an instance of a business process. The
PRCA technique which is based on the QoBP framework models (specifi-
cally the softgoal correlation model and the measurement model) adheres to
the desirable criteria for a root cause analysis technique that were presented
in Section 4.5.1.
65 Repeat of Step 3 of the PRCA technique.66 Step 4 of the PRCA technique.67 Step 5 of the PRCA technique.68 Step 6 of the PRCA technique.
4.6 127
The PRCA technique is comprehensive as it provides the investigator
with the ability to identify the sequence of all events leading to a cause of
a quality issue in a business process through the softgoal correlation model
that is created for the business process. This technique is context-aware
which means it provides investigators the appropriate information required
to conduct corrective actions, such as the context in which the quality is-
sue has occurred. The context is provided via the quality metrics and their
associated values at process instance level. For example, the software engi-
neer experience and value of 1 for the specific instance of the RFP process
that was being investigated provided the context in which the quality issue
occurred. The PRCA technique is a systematic approach as it provides a
consistent step-by-step procedure to conduct the investigation. The PRCA
technique is easy to use. Once the QoBP framework models are created for a
business process, the root cause analysis can be conducted by just following
the steps listed above (in Section 4.5.2). As mentioned in Section 4.5.1, the
PRCA technique will be evaluated again against these criteria during the
action research phase of this research69.
4.5.3 Summary of Quality Improvement - PRCA Section
This section presented the PRCA technique which was developed to sup-
port the quality improvement phase of the quality-aware BPM life cycle.
The PRCA technique provides a root cause analysis approach for business
processes. It provides a mechanism to improve the quality of business pro-
cesses by reactively analysing and addressing quality issues. The PRCA
technique is a systematic procedure that is comprehensive, context-aware
and easy to use.
4.6 Chapter Summary
This chapter presented Part 2 of this thesis which was dedicated to the
design science phase of this research. The purpose of this chapter was to
present the artifacts developed during the design phase of this research
which address the research questions that drove this study. These artifacts
69 As described in Section 3.2, the artifacts that were built during the design phase will beevaluated by conducting three cycles of action research. Chapters 6, 7, and 8 will presentthree cycles of the action research cycle conducted in this research.
128 4 The Design Science Phase
were presented in four section (Sections 4.2, 4.3, 4.4 and 4.5). Section 4.2
presented the quality-aware BPM life cycle developed by this research to
address the main research question: “How can quality be incorporated into
a business process and managed during the BPM life cycle?”. In the pro-
posed quality-aware BPM life cycle, the quality of a business process is
managed based on the four key phases of: quality definition, quality im-
plementation, quality control, and quality improvement. The introduction
of the quality-aware BPM life cycle led to further research questions that
formed the scope and structure of this study. For the purpose of this thesis
the scope was limited to the research questions related to the first and last
phases of the quality-aware BPM life cycle: quality definition and quality
improvement. Sections 4.3 and 4.4 were dedicated to the artifacts that were
developed to address the research questions related to the quality defini-
tion phase, while Section 4.5 presented the artifact that was developed to
address the research question related to the quality improvement phase of
quality-aware BPM life cycle. Section 9 presents in detail how the research
questions that drove this study were addressed by the artifacts proposed in
this chapter.
The artifacts presented in this chapter, developed during the design phase
of this study will be evaluated during the action research phase of this study.
The next four chapters (Part 3) will present the action research phase of
this study. The first chapter of Part 3 (Chapter 5) presents a protocol for
conducting the action research. Chapters 6, 7 and 8 present three action
research cycles conducted in three large Australian organisations to evaluate
the artifacts developed during the design science phase.
Part III
Action Research Phase
5
Action Research Protocol
5.1 Introduction
This opening chapter for Part 3 of this thesis is dedicated to the action
research phase. This chapter describes how the key principles of action re-
search, identified in Chapter 3, will be applied to the action research phase
of this research.
This chapter describes the protocol for conducting action research in this
study for the purpose of evaluating artifacts that were built during the de-
sign phase. These artifacts were presented in chapter 4.
The justification for using a multi-method methodology in this research
(based on design science and action research) was presented in Section 3.2.
As described in Section 3.5, the action research adapted for this research is
based on the five stages of the action research methodology proposed in [3]
which are diagnosis, action planning, action taking, evaluation, and speci-
fying learning.
The quality and rigor of action research relates to: (1) how data is gener-
ated, gathered, explored and evaluated; (2) how the principal researcher is
engaged in the different stages of the action research cycles; and (3) method-
ological data collection approaches such as templates and measurement tools
[182]. The protocol elements presented in this chapter ensure the rigor of
the action research being conducted in this study. Accordingly, this chapter
provides a guide for selecting an appropriate host organisation for the action
research (Section 5.2), plan of engagement (Section 5.3), guidelines for pro-
132 5
cedures related to organisation visits (Section 5.3), templates to use during
the various activities (Section 5.3), and the reporting format (Section 5.4).
These elements ensure the rigor of the action research conducted as part of
this study.
5.2 Selection of Organisations
Ideally, to gain maximum outcome from the action research phase, certain
criteria for the selection of an appropriate host organisation must be met.
The organisations will be selected based on these selection criteria:
• Criterion 1 - It is important for the organisation to have an apprecia-
tion for BPM and commitment to BPM principles and practices.
• Criterion 2 - It is important for the organisation to have an apprecia-
tion for research in the area and preferably a prior relationship with the
BPM research center within the Queensland University of Technology.
• Criterion 3 - It is important for the organisation to have an appreciation
for quality aware BPM and be keen to introduce the quality framework
proposed by this thesis to their BPM practice.
• Criterion 4 - It is preferred that the organisation is in a location that
is readily accessible to the researcher.
The following section presents the engagement plan and approach with
the host organisations during the action research cycles (Section 5.3).
5.3 Action Research Plan
As mentioned in a previous chapter (Section 3.2 of chapter 3), three action
research cycles will be conducted within three large organisations to evalu-
ate the artifacts developed during the design science phase (Chapter 4). The
5.3 Action Research Plan 133
artifacts being evaluated by action research are: the models1 of the QoBP
framework, the QoBP metamodel (see Section 4.4.5.2), the QoBP method-
ology (see Section 4.4.6)), and the PRCA technique (see Section 4.5.2).
This section presents the plan of engagement with the host organisations
for the Action Research part of this study. It is envisaged that informal
meetings and workshops will provide the majority of the interactions with
the host organisations. Communications are known to be important dimen-
sion of the workshops [183], therefore they need to be structured to ensure an
effective communication. The researcher should ensure that the communica-
tions during the workshops are structured based on three behaviours [184]:
knowledge acquisition, knowledge negotiation, and acceptance. Knowledge
acquisition refers to the part of communication that is focused on sharing
the knowledge between the participants during the workshops. Once the
topics of discussion are more explicit, they need to be negotiated as part of
an iterative process referred to as knowledge negotiation. Acceptance im-
plies integration of workshop participants viewpoints where all parties agree
on the outcome of the discussion.
For meetings and workshops, the agendas will be distributed in advance
to appropriate parties, and minutes from the meetings will be recorded us-
ing a standard template (as provided in Appendix B.1 and Appendix B.2).
Throughout the action research phase, the researcher will record notes and
reflections related to each case.
Figure 5.1 presents a summary of the proposed engagement plan during
the different stages of the action research. Activities with respect to each
stage of the action research plan are described in the following sub-sections.
5.3.1 Initial Engagement
After selecting the prospect organisations, a letter will be sent to each or-
ganisation inviting them to participate in the research2. The researcher then
1 The QoBP framework models are: the quality model (see Section 4.3), the softgoal model (see4.4.2), the softgoal correlation model (see 4.4.3), and the measurement model (see 4.4.4).
2 The invitation letter is exhibited in Appendix B.3.
134 5 Phase Sub-A ctivity Engagem ent Type D uration In itia l Engagem ent Initia l K ick off Inform al M eeting 2 hours A ction R esearch Cycle – D iagnosis Identify the problem Inform al M eeting 4 hours A ction R esearch Cycle – A ction P lanning D efine the Project Scope Inform al M eeting 1 hour P lan A ctivities Inform al M eeting 2 hours Schedule Inform al M eeting 1 hour A ction R esearch Cycle – A ction Taking P hase I A nalyse the P rocess W orkshop 4 hours C reate B usiness P rocess M odel W orkshop 16 hours C reate Q uality M odel W orkshop 16 hours C reate Softgoal M odel W orkshop 16 hours C reate C orrelations M odel N one 4 hours C reate M easurem ent M odel W orkshop 8 hours P repare Proje ct R eport N one 40 hours A ction R esearch Cycle – A ction Taking P hase II C onduct R oot C ause A nalysis W orkshop 8 hours A ction R esearch Cycle – Eva luating Eva luate Q oB P Fram ew ork W orkshop 16 hours P resent Eva luation R esults W orkshop 20 hours A ction R esearch Cycle – Specifying Learning Identify Enhancem ent O pportunities to Q oB P Fram ew ork W orkshop 8 hours P repare Report N one 40 hours C losure F ina l M eeting Inform al M eeting 4 hours Tota l H ours: 210 hours
Fig. 5.1. Action Research Engagement Plan
will organise a meeting with each organisation to discuss this collaborative
opportunity in detail. A summary of the research topic and the action re-
search approach will be distributed to the appropriate parties prior to the
first meeting3. During the initial meeting the action research process and
plan will be described by the researcher to the parties involved.
3 A copy of the summary is presented in Appendix B.4.
5.3 Action Research Plan 135
5.3.2 Diagnosis Stage
Diagnosis is the first stage of the action research cycle. The purpose of this
stage is to:
• Describe the purpose of the action research and its benefits to the or-
ganisation.
• Identify a business process within the organisation that can be improved
using the framework proposed by this research.
During this stage, the researcher will conduct informal meetings with
the key stakeholders within the host organisation. The meetings are envis-
aged to be up to 4 hours duration. During these meetings the researcher
will describe the purpose of the action research, and how the host organi-
sation will benefit from the introduction of the Quality of Business Process
(QoBP) framework to their BPM practice. An appropriate process that will
benefit from the QoBP framework is selected during these meetings.
5.3.3 Action Planning Stage
The purpose of this stage is to plan the activities that are performed during
the course of the collaboration to solve the identified problem. The activity
plan will be based on activities that are required to be performed in two
phases:
• Phase I - To create a quality-aware business process during the qual-
ity definition phase of the quality-aware BPM life cycle. The activity
plan for this phase is based on the procedural steps proposed by the
QoBP methodology (presented in Section 4.4.6) which are: (1) analyse
the business process, (2) define a business process model, (3) create a
quality model, (4) create a softgoal model, (5) create a softgoal correla-
tion model, and (6) create a measurement model.
136 5
• Phase II - To conduct root cause analysis in order to improve the quality
of a business process during the quality improvement phase of the quality-
aware BPM life cycle. The activity plan for this phase is based on the
PRCA technique presented in Section 4.5.2.
During this stage, the researcher will conduct informal meetings with key
stakeholders within the host organisation. The meetings are envisaged to be
up to 4 hours duration. During these meetings, the researcher will plan the
above activities with the key stakeholders. An action research cycle may
only be planned for just one phase (i.e. phase one).
5.3.4 Action Taking Stage
The purpose of this stage is to perform the activities identified during the
action planning stage. The researcher will organise a series of workshops
with the key stakeholders in the organisation according to the action plan
produced during the action planning stage. The workshops, in general, have
two different focuses: (1) data collection; and (2) validation of the model
created after the data collection. The validation at this point is different to
the validation stage presented in Section 5.3.5. At this stage the aim is to
verify with key participants that the data captured and modelled are correct.
The action taking stage is based on the action plan created during the
action planning stage. The action taking stage is divided into two phases
which are presented in the following two sub-sections.
5.3.4.1 Action Taking Stage - Phase I
The purpose of this stage is to perform the activities identified for phase I
of the action taking stage. As described in Section 5.3.3, the action plan for
phase I is based on the procedural steps proposed by the QoBP methodology
presented in Section 4.4.6. This section complements the QoBP methodol-
ogy by providing some guidelines on how to perform each procedural step of
the QoBP methodology and what tools (e.g. templates) to use during each
step. These six steps are presented below.
5.3 Action Research Plan 137
5.3.4.1.1 Step 1 - Analyse the Business Process
The purpose of the first step is to analyse the organisational structure, the
process goals, the process environment, and the quality requirements of the
process being analysed.
During this stage, the researcher will organise a workshop inviting rele-
vant parties to analyse the business process. Conversational methods [185]
such as workshops are known to be effective for requirements analysis as
all the key stakeholders are in the room contributing to the analysis activ-
ity [186]. The researcher should follow the three communication behaviours
(knowledge acquisition, knowledge negotiation, and user acceptance) rec-
ommended by [184] to ensure the communications during the workshops
are structured and effective. The functional and quality (non-functional)
requirements of the process will be elicited during the workshop, taking
account of the organisation’s strategy, goals and structure. The deliverable
of this step will be a document describing the functional and quality (non-
functional) requirements, in plain English, of the business process being
analysed.
5.3.4.1.2 Step 2 - Create a Business Process Model
The purpose of this step is to model the selected process using a business
process modelling language.
During this stage, the researcher will organise a series of workshops invit-
ing relevant parties to model the business process based on the requirements
defined and documented during the previous step.
The business process modelling notation and methodology practiced by
the host organisation will be used during this modelling exercise. The de-
liverable of this step will simply be a business process model created using
a business process modelling notation such as EPC4. It is envisaged that up
to 4 workshops of 4 hours each is required to complete this step.
4 Refer to Appendix A.1 for further details on Event-Drive Process Chain (EPC).
138 5
5.3.4.1.3 Step 3 - Create a Quality Model
The purpose of this step is to define a quality model for the selected busi-
ness process and based on the quality requirements defined during the first
step (see Section 6.4.4.1).
The researcher will need to organise four workshops to capture the quality
characteristics for the four business process quality dimensions (functions,
inputs-outputs, human resources, and non-human resources). The outcome
of these workshops is a quality model consisting of the quality characteris-
tics for the four dimensions of the business process. The method to capture
quality characteristics for these dimensions is presented below.
3.1) Function quality dimension
A list of possible quality characteristics for the function quality dimen-
sion was presented in Section 4.3.2.1 of chapter 4.4. As mentioned in Sec-
tion 4.3.2.1, these quality characteristics can be relevant for a function,
but may not be all applicable for every function. For example, safety is
not necessarily an applicable quality characteristic for the process payment
function of the invoice payment process. The list of characteristics (from
Section 4.3.2.1) will help the key stakeholders identify quality characteris-
tics of the functions of an individual process. Accordingly, the aim of the
workshop at this stage is to assist the key stakeholders to select the applica-
ble quality characteristics for the functions of the selected business process.
It is crucial during this step to ensure the quality characteristics selected
for the process are aligned with the quality requirements defined during the
first step. Therefore, the first exercise is to map the high level quality re-
quirements defined during the step 1 to the process functions. This mapping
associates each defined quality requirement to one or more functions of the
selected process.
To make the QoBP framework more flexible and practical in the com-
mercial world where projects are constrained by budget and time, three ap-
proaches are provided for this stage. For the projects with no time and bud-
get constraints, the key stakeholders can select as many of the quality char-
acteristics of the function quality dimension (presented in Section 4.3.2.1) as
5.3 Action Research Plan 139
they wish. Alternatively, for the projects with time and budget constraints,
the key stakeholders have the option to limit the number of applicable qual-
ity characteristics for each function. The last approach provides a limit on
the maximum number of selections which can vary for each project (de-
pending on the project’s budget and time constraints). The two approaches
proposed for projects with time and budget constraints differ in that the
first one will enforce the key stakeholders to focus on each function and
select the top 3 characteristics5 for each function irrespective of the whole
process. The second approach enforces the key stakeholders to focus on the
whole process by selecting the top 3 relevant functions for each character-
istic.
To assist the workshop participants three function-quality matrix tem-
plates (Figures 5.2, 5.3, and 5.4) are provided to capture the quality char-
acteristics for the functions of the business process. These three function-
quality matrices provide a mechanism to highlight the relative importance
of the different quality characteristics for functions of the process. In each
of these matrices each row represents a function of the business process and
the columns represent the quality characteristics of the function dimension.
The cells of the matrix therefore represent a unique function/quality char-
acteristic combination and a value can be applied to score or rate the func-
tion/quality characteristic combination (depending on the rating method
used).
Figure 5.2 presents the template for the first rating method. The first
rating method uses a boolean value (Yes/No) to specify whether a quality
characteristic is important for a function. Once a value has been deter-
mined for each function/quality characteristic combination then a count of
the ’Yes’ values in each column and row is performed. The count for each
row provides a rating of the relative importance of quality to the various
functions within the process. The count for each column indicates the rela-
tive importance of the quality characteristics for the process. The function
total and the quality characteristic total provide a quick way to identify 1)
the functions that play an important role in the quality of the process, and
5 Any limit on the number of characteristics can be selected based on the project constraints.Three characteristics are selected here for illustration purposes.
140 5
Suitability Accuracy Security Reliability Understandability Learnability Time behaviou
r efficiency Resource utilisation Effectiveness Productivity Safety Satisfaction Robustness Total… 0Formulate a solution Y Y Y Y Y Y Y Y Y Y 10Esitimate Y Y Y Y Y Y Y 7… 0Formulate RFP response Y Y Y Y Y Y Y Y 8… 0000000Total 2 3 0 3 3 0 3 3 3 3 0 1 1
Function dimension quality characteristics
“Y“ indicates that accuracy is a desired quality characteristic for
the function “Estimate”
Total in each row provides the totals
number of characteristics for
each function.
The highest totals presents the quality
characteristics that are important for the process
Total in each column presents the relative importance of the quality
characteristics for the process
Function dimension quality
characteristics
Functions of
Request for Proposal
(RFP) process
“Formulate a solution” with the highest total plays an important role in the quality of the RFP process
Fig. 5.2. Function Quality Dimension (captured as yes or no)
2) the quality characteristics that are important for the process.
Suitability Accuracy Security Reliability Understandability Learnability Time behavio
ur efficiency Resource utilisation Effectiveness Productivity Safety Satisfaction Robustness…Formulate a solution 3 2 1Estimate 1 3 2…Formulate RFP response 3 2 1…
Total 7 3 0 4 0 0 0 0 0 2 0 2 0
Functions of
Request for Proposal
(RFP) process
Function dimension quality
characteristics
“Suitability” with the highest total, is the most important quality
characteristic for the RFP process
Total in each column presents the relative importance of the quality characteristics for the process
Rating Process:For each function select the top 3 relevant quality characteristics
“3“ indicates that “accuracy” is the most important quality
characteristic for the function “Estimate”
“1“ indicates that “suitability” is the third most important quality characteristic for
the function “Estimate”
Fig. 5.3. Function Quality Dimension (by rows - quality characteristics)
Figure 5.3 presents the template for the second rating method. This rat-
ing method uses an approach where each function is evaluated to determine
5.3 Action Research Plan 141
the top 3 quality characteristics6 that are important to that function. These
are then ranked and a value of 3 is applied to the most important quality
characteristic, a value of 2 is applied for the second most important qual-
ity characteristic and a value of 1 is applied to the third most important
quality characteristic. After this process has been performed for each of
the functions the sum of the values for each of the quality characteristics
is totaled. This provides a rating of the relative importance of each of the
quality characteristics for the process.
Figure 5.4 presents a complementary template for the second rating
method. This rating method uses an approach whereby each quality char-
acteristic is evaluated to determine the top 3 functions that are important
to that quality characteristic. These are ranked and a value of 3 is applied
to the most important function, a value of 2 is applied for the second most
important function and a value of 1 is applied to the third most important
function. After this process has been performed for each of the quality char-
acteristics the sum of the values for each of the functions is totaled. This
provides a rating of the relative importance of quality to each functions of
the process.
3.2) Input &Output quality dimension
A list of possible quality characteristics for the input &output quality di-
mension was presented in Section 4.3.2.2. As mentioned in Section 4.3.2.2,
the quality characteristics can be relevant for an input or output of a func-
tion, but not all are applicable for every input and output of a function. For
example, timeliness is not necessarily an applicable quality characteristic for
the customer name input of the invoice payment process while it is some-
what important for the customer address input of the invoice payment. The
list of characteristics will help the key stakeholders rate the quality char-
acteristics of particular input and output data of an individual function of
a process. Accordingly, the aim of the workshop at this stage is to assist
the key stakeholders to rate the applicability of the quality characteristics
to inputs and outputs of the functions of the selected business process. To
6 This matrix is introduced to allow the business to choose the top 3 most important character-istics for a function. Depending on the time and resource constraints, the business stakeholderscan determine the number of characteristics to select for each function.
142 5
Suitability Accuracy Security Reliability Understandability Learnability Time behaviou
r efficiency Resource utilisation Effectiveness Productivity Safety Satisfaction Robustness Total… 1 3 3 7Formulat a solution 3 1 3 3 3 1 3 2 3 22Estimate 3 1 2 2 1 1 10… 3 1 2 2 8Formulate RFP Response 2 2 2 1 3 2 3 2 17… 1 2 2 1 1 1 8000000
Functions of
Request for Proposal
(RFP) process
Total in each row provides the totals
number of characteristics for
each function.
“Formulate a solution” with the highest total plays an important role in the quality of the RFP process
“1“ indicates that “suitability”, “…” is the the
third most relevant function
“3“ indicates that for “suitability”, “formulate a solution” is the most
relevant function
Rating P
rocess:F
or each characteristic select the top 3 relevant function
Function dimension quality
characteristics
Fig. 5.4. Function Quality Dimension (by columns - quality characteristics)
rate the importance of each quality characteristic for an input or output of
a function a 5 level scale will be used, as a 3 level scale or boolean value (yes
& no) will not be granular enough. The scales in the 5 level scale include:
1. Not Important - this scale indicates that the quality characteristic is
not important. When it is given to a quality characteristic, it indicates
that a common failure is expected and it is acceptable. For example,
this rating can be given to the timeliness quality characteristic for the
customer name input of the process payment function of the invoice pay-
ment process.
2. Somewhat Important - this scale indicates that basic quality is re-
quired. This rating is given to a quality characteristics where regular
failure is expected and is acceptable. For example, this rating can be
given to the timeliness quality characteristic for the customer address
input of the process payment function of the invoice payment process.
3. Frequently Important - this scale indicates that this specific quality
characteristic for an input or output contributes to the quality of the
process as a whole. When this rating is given to a quality characteristic,
a certain level of exception handling will need to be built into the pro-
cess, with occasional failure expected (less than 10% failure is expected).
5.3 Action Research Plan 143
For example, this rating can be given to the accuracy quality character-
istic for the customer name output of the calculate payment function of
the invoice payment process.
4. Always Important - this scale indicates that this specific quality char-
acteristic for an input or output contributes to the quality of the process
as a whole. When this rating is given to a quality characteristic, a certain
level of exception handling will need to be built into the process, with
minimum failure expected (less than 1%). For example, this rating can
be given to the accuracy quality characteristic for the payment amount
output of the calculate payment function of the invoice payment process.
5. Critically Important - this scale indicates that this specific quality
characteristic for an input or output contributes to the quality of the
process as a whole. When this rating is given to a quality characteristic,
maximum level of exception handling will need to be built into the pro-
cess (0 failure is expected). This rating is given to a quality characteristic
where poor quality will cause process failure. For example, this rating can
be given to the accuracy quality characteristic for bank account details
input of the process payment function of the invoice payment process.
To assist workshop participants a matrix template (figure 5.5) is provided
to capture the quality characteristics for inputs & outputs of functions of the
business process. This template will provide a mechanism to highlight the
relative importance of the different quality characteristics for each input &
output of the process. In this matrix each row represents an input or output
of the business process and the columns represent the quality characteristics
of the input & output dimension. The cells of the matrix therefore represent
a unique input-output/quality characteristic combination and a value can
be applied to score or rate the input-output/quality characteristic. Each
quality characteristic will be given a rating between 1 to 5 with respect to
the input or output of the function being analysed.
3.3) Human Resources quality dimension
A list of possible quality characteristics for the human resource quality di-
144 5
Function Inputs Outputs Accuracy Objectivity Believability Reputation Accessibility Security Relevancy Value-added Timeliness Completeness Amount of data
… … …Formulate a solution RFP 1 3 3 3 1 1 4 2 2 5 5Formulate a solution Solution 2 4 4 4 1 1 5 5 4 5 5Estimate Solution 2 4 4 4 1 1 5 5 4 5 5Estimate Estimate 5 5 5 5 4 1 4 5 5 5 5… …Formulate RFP response Solution 2 4 4 4 1 1 5 5 4 5 5Formulate RFP response Estimate 5 5 5 5 4 1 4 5 5 5 5Formulate RFP response RFP Response 5 5 5 5 4 1 4 5 5 5 5… …
Input & Output dimension quality
characteristics
5 indicates that “accuracy” is critically important for
“RFP response”
4 indicates that “accessibility” is always important for “RFP
response”
1 indicates that “security” is not important for “RFP
response”
2 indicates that “timeliness” is
somewhat important for
“RFP”
3 indicates that “objectivity” is frequently
important for “RFP”
Functions of
Request for Proposal
(RFP) process
Fig. 5.5. Input & Output Quality Dimension
mension was presented in Section 4.3.2.3. As mentioned previously, these
quality characteristics can be relevant, but not all will be applicable for
every human resource. For example, qualification is not necessarily an ap-
plicable quality characteristic for a clerk responsible for process payment
function of the invoice payment process. The list of characteristics will help
the key stakeholders identify quality characteristics of human resources of
an individual process. Accordingly, the aim of the workshop at this stage is
to assist the key stakeholders to select the applicable quality characteristics
for human resources of the selected business process.
Figure 5.6 presents a matrix template which provides a tool for capturing
the quality characteristics for the human resources quality dimension. This
template will provide a mechanism to highlight the relative importance of
the different quality characteristics for human resources allocated to func-
tions of the process. In this matrix each row represents a function of the
business process and the columns represent the quality characteristics of
the human resource dimension. The cells of the matrix therefore represent
a unique human-resource/quality characteristic combination. This matrix
uses a boolean value (Yes/No) to specify whether a quality characteristic is
important for the human resource allocated to a function. Once a value has
5.3 Action Research Plan 145
Human resource dimension quality
characteristics
Total in each row provides the totals
number of characteristics for
each human resource
Function Human Resource Domain Knowledge Qualification Certification Experience Time Managem
entCommunication Skill Leadership Total… … 0Formulate a solution Solution Architect Y Y Y Y Y 5Estimate Solution Architect Y Y Y Y Y 5… … 0Formulate RFP response Project Manager Y Y Y Y Y Y 600Total 3 2 1 3 3 3 1
“Project Manager” with the highest
total plays an important role in the quality of the
RFP process
The highest totals presents the quality
characteristics that are important for the process
Total in each column presents the relative importance of the quality characteristics for the process
Functions of
Request for Proposal
(RFP) process
“Y“ indicates that “domain knowledge” is a relevant quality
characteristic for the “project manage” formulating the RFP response
Fig. 5.6. Human Resource Quality Dimension
been determined for each human-resource/quality characteristic combina-
tion then a count of the ’Yes’ values in each column and row is performed.
The count for each row provides a rating of the relative importance of qual-
ity to the various functions within the process. The count for each column
indicates the relative importance of the human resource quality character-
istics for the process.
3.4) Non-Human Resources quality dimension
A list of possible quality characteristics for the non-human resource quality
dimension was presented in Section 4.3.2.4. As mentioned in Section 4.3.2.4,
these quality characteristics can be relevant for a resource, but not all are
applicable for every resource. For example, safety is not necessarily an ap-
plicable quality characteristic for the payment processing system used as a
resource for the process payment function of the invoice payment process.
This list of characteristics will help the key stakeholders identify quality
characteristics of particular non-human resources of an individual process.
Accordingly, the aim of the workshop at this stage is to assist the key
stakeholders to select the applicable quality characteristics for non-human
resources required for functions of the selected business process.
146 5
To make the QoBP framework more flexible and practical in the com-
mercial world where projects are constrained by budget and time, the ap-
proaches for the function dimension are also applicable to the non-human
resource dimension.
Three non-human-resource-quality matrix templates are provided to cap-
ture the quality characteristics for the non-human resources of the business
process. These three matrices will provide a mechanism to highlight the
relative importance of the different quality characteristics for non-human
resources of the process. In each of these matrices each row represents a
non-human resource for a function of the process and the columns repre-
sent the quality characteristics of the non-human resource dimension. The
cells of the matrix therefore represent a unique non-human resource/quality
characteristic combination and a value can be applied to score or rate the
function/quality characteristic combination.
Total in each row provides the totals
number of characteristics for
each function.
The highest totals presents the quality
characteristics that are important for the process
Total in each column presents the relative importance of the quality
characteristics for the process
Non-human resource dimension quality
characteristics
Functions of
Request for Proposal
(RFP) process
Function Non-Human Resource Suitability Accuracy Security Reliability Understandability Learnability Time behaviou
r efficiency Resource utilisation Effectiveness Productivity Safety Satisfaction Robustness Total
… 0Formulate a solution UML Tool Y Y Y Y Y Y Y Y Y Y 10Estimate Estimation Tool Y Y Y Y Y Y Y Y Y Y Y 11… 0Formulate RFP response Project Management Tool Y Y Y Y Y Y Y Y Y Y Y Y 12… 0000000Total 3 2 1 3 3 3 3 3 3 3 0 3 3“Y“ indicates that accuracy is a desired quality characteristic for
“Estimation Tool”
“Project Management Tool”
with the highest total plays an
important role in the quality of the
RFP process
Fig. 5.7. Non-Human Resource Quality Dimension (captured as yes or no)
Figure 5.7 presents the template for the first rating method. The first
rating method uses a boolean value (Yes/No) to specify whether a quality
characteristic is important for a non-human resource. Once a value has been
determined for each non-human resource/quality characteristic combination
5.3 Action Research Plan 147
then a count of the ’Yes’ values in each column and row is performed. The
count for each row provides a rating of the relative importance of quality
to the various non-human resources within the process. The count for each
column indicates the relative importance of the quality characteristics for
the process.
Functions of
Request for Proposal
(RFP) process
Non-human resource dimension quality
characteristics
Total in each column presents the relative importance of the quality
characteristics for the process
Function Non-Human Resource Suitability Accuracy Security Reliability Understandability Learnability Time behaviou
r efficiency Resource utilisation Effectiveness Productivity Safety Satisfaction Robustness…Formulate a solution UML Tool 3 1 2Estimate Estimation Tool 1 3 2…Formulate RFP response Project Management Tool 3 2…
Total 7 3 0 4 1 0 0 0 0 2 0 0 0
“3“ indicates that “accuracy” is the most important quality
characteristic for the “Estimate Tool”
“1“ indicates that “suitability” is the third most important quality characteristic for the “Estimation
Tool”
Rating Process:For each resource select the top 3 relevant quality
characteristics
“Suitability” with the highest total, is the most important quality
characteristic for the RFP process
Fig. 5.8. Non-Human Resource Quality Dimension (by rows - quality characteristics)
Figure 5.8 presents the template for the second rating method. The sec-
ond rating method uses an approach whereby each non-human resource is
evaluated to determine the top 3 quality characteristics7 that are important
to that function. These are then ranked and a value of 3 is applied to the
most important quality characteristic, a value of 2 is applied for the second
most important quality characteristic and a value of 1 is applied to the third
most important quality characteristic. After this process has been performed
for each of the non-human resources within the process the sum of the values
for each of the quality characteristics is totaled. This provides a rating of
7 This matrix is introduced to allow the business to choose the top 3 most important character-istics for a non-human resource. Depending on the time and resource constraints, the businessstakeholders can determine the number of characteristics to select for each non-human re-source.
148 5
the relative importance of each of the quality characteristics for the process.
Functions of
Request for Proposal
(RFP) process
Total in each row provides the totals
number of characteristics for
each resource.
“1“ indicates that for “suitability”, “Project
Management Tool” is the third most relevant resource
“3“ indicates that for “suitability”, “UML Tool” is the most relevant
resource
Non-human resource dimension quality
characteristics
Function Non-Human Resource Suitability Accuracy Security Reliability Understandability Learnability Time behaviour
efficiency Resource utilisation Effectiveness Productivity Safety Satisfaction Robustness Total
… 3 3Formulate a solution UML Tool 3 1 1 3 1 1 3 1 2 3 2 21Estimate Estimation Tool 2 3 2 2 3 3 1 2 1 1 1 21… 2 2Formulate RFP response Project Management Tool 1 2 3 1 2 2 2 3 3 2 3 24… 1 1
Ratin
g P
r oc ess :
Fo
r e ach ch
ara cte risti c s ele ct t he
t op
3 rel eva nt res o
urce
“Project Management Tool”
with the highest total plays an
important role in the quality of the
RFP process
Fig. 5.9. Non-Human Resource Quality Dimension (by columns - quality characteristics)
Figure 5.9 presents the template for the third rating method. The third
rating method uses an approach whereby each non-human resource charac-
teristic is evaluated to determine the top 3 non-human resources that are
important to that quality characteristic. These are then ranked and a value
of 3 is applied to the most important non-human resource, a value of 2 is
applied for the second most important non-human resource and a value of
1 is applied to the third most important non-human resource. After this
process has been performed for each of the quality characteristics the sum
of the values for each of the non-human resources is totaled. This provides
a rating of the relative importance of quality to each of the non-human re-
sources for the process.
5.3.4.1.4 Step 4 - Create a Softgoal Model
The objective of this step is to create a softgoal model for the quality char-
acteristics modelled in the quality model created in the previous step.
5.3 Action Research Plan 149
As described in Section 4.4.2, the quality characteristics in the QoBP
framework may be subjective, implicit, context-specific and imprecise8.
Therefore, to evaluate quality characteristics, they are need to be further
refined into a set of softgoals.
Accordingly, the researcher will organise a series of workshops to specify
softgoals for the quality characteristics identified during the previous step.
The researcher will use the softgoal specification recommended in Section
4.4.2. It is envisaged that 4 workshops of 4 hours each will be required to
complete this step.
Function Quality Characteristic Softgoal…Formulate a solution Suitability To increase the suitability of the ''formulate solution" Estimate Accuracy To increase the accuracy of "estimate"… … …Formulate RFP response Reliability To increase the reliability of "formulate RFP response"… … …
A function of the RFP process
The quality characteristic selected for “Formulate a
solution” function
The softgoal specified for the suitability
characteristic
Fig. 5.10. Function Softgoals Template
Four templates are provided to create the softgoal model for the selected
business process. Figure 5.10 presents the first template which will be used
to capture softgoals for quality characteristics identified for the functions of
the selected process. With each row in the table representing a softgoal for
a function quality characteristic of the selected business process.
Figure 5.11 presents the second template which will be used to capture
softgoals for quality characteristics identified for the inputs and outputs of
8 Refer to Section 4.4.1 for further details on subjectivity, implicity, context- specificity, andimpreciseness of quality characteristics.
150 5
Function Input/Output Quality Characteristic Softgoal… … …Formulate a solution RFP Relevancy To increase the relevancy of the "RFP"Formulate a solution Solution Completeness To increase the completeness of the "solution"Estimate Estimate Accuracy To increase the accuracy of "estimate"… … … …Formulate RFP response RFP Response Reputable To increase the reputability of the "RFP response"… … …
A function of the RFP process
The quality characteristic selected for “RFP” input
The softgoal specified for the relevancy
characteristic
An input to the “formulate a solution”
function
Fig. 5.11. Input & Output Softgoals Template
the selected process. Each row in the table represents a softgoal for an input
or output quality characteristic of a function of the selected business process.
Function Human Resource Quality Characteristic Softgoal… … …Formulate a solution Software Engineer Qualification To enforce the qualification of the "Software Engineer"Estimate Software Engineer Qualification To enforce the qualification of the "Software Engineer"… … …Formulate RFP response Software Engineer Certification To enforce the certification of the "Software Engineer"… … …
A function of the RFP process
The quality characteristic selected for the “Software
Engineer”
The softgoal specified for the qualification
characteristic
A human resource for the “formulate a
solution” function
Fig. 5.12. Human Resource Softgoals Template
Figure 5.12 presents the third template which will be used to capture
softgoals for quality characteristics identified for the human resources of the
selected process. Each row in the table represents a softgoal for a human
resource quality characteristic of a function of the selected business process.
Figure 5.13 presents the fourth template which will be used to capture
softgoals for quality characteristics identified for the non-human resources
of the selected process. Each row in the table represents a softgoal for a non-
human resource quality characteristic of a function of the selected business
5.3 Action Research Plan 151
Function Non-Human Resource Quality Characteristic Softgoal… … … …
Formulate a solution UML Tool Suitability To increase the suitability of the "UML Tool"Estimate Estimation Tool Accuracy To increase the suitability of the "Estimation Tool"… … … …Formulate RFP response Project Management Tool Reliability To improve the reliability of the "Project
Management Tool"… … … …
A function of the RFP process
The quality characteristic selected for the “UML
Tool”
The softgoal specified for the suitability
characteristic
A non-human resource for the “formulate a solution” function
Fig. 5.13. Non-Human Resource Softgoals Template
process.
5.3.4.1.5 Step 5 - Create a Softgoal Correlation Model
The purpose of this step is to identify the correlations between the softgoals
identified during the last step9.
As described in the sections 4.4.3, the softgoal correlation model will be
used to conduct root cause analysis of quality issues in a business process.
The researcher will create the softgoal correlation model based on the algo-
rithm proposed in the Section 4.4.6.510.
Figure 5.14 presents the template that will be used by the researcher to
capture the softgoal correlation model. This template simply presents the
relationship between functions of a business process based on the softgoal
correlations. As shown in figure 5.14 the template lists the data inputs for
each function. For each of these data inputs a link is established to the
earlier functions that have output this data and the softgoals of this earlier
function are then mapped to the later function.
9 Refer to Section 4.4.6.5 for further details on how to create a softgoal correlation model.10 The researcher can perform this task without any contribution from the host organisation.
152 5
Function Input Linked Function Correlated SoftgoalFormulate RFP response Estimate Estimate To ensure the function produces accurate resultsFormulate RFP response Estimate Estimate To ensure the function is not susceptible to failure… … … …Estimate Solution Formulate a solution To ensure the formulated solution is adequate with respect to the specified objectives… … … ..
``Estimate’’ function is linked to “formulate RFP response” via its output
“Estimate”
Softgoal identified for ``Estimate`` function
``Estimate” is an input to the “formulate RFP response” function
Fig. 5.14. Softgoals Correlation Template
5.3.4.1.6 Step 6 - Create a Measurement Model
The purpose of this step is to create a model which contains metrics re-
quired to measure softgoal satisfaction.
This step is the last step of the goal-oriented approach to transform the
subjective quality characteristics into a set of measurable, objective quality
metrics. As described in Section 4.4.6.6, the Goal-Question-Metric (GQM)
approach by [147] is adapted to identify the quality metrics for softgoals
identified during the previous step. Accordingly, the researcher will organ-
ise a series of workshops to identify metrics using the Goal-Question-Metric
(GQM) approach11. It is envisaged that up to 4 workshops of 4 hours each
is required to complete this step.
Four templates are provided to create the measurement model for the
selected business process. Figure 5.16 presents the first template which is
used to capture quality metrics and their relevant threshold values for the
softgoals identified for the functions of the selected process. Each row in the
table presents a metric for a softgoal of a function of the selected business
process.
Figure 5.16 presents the second template which is used to capture quality
metrics and their relevant threshold values for the softgoals identified for the
inputs and outputs of the selected process. Each row in the table presents a
11 Refer to Section 4.4.6.6 for further details GQM approach adapted for this step.
5.3 Action Research Plan 153
Function Quality Characteristic Softgoal Metric Threshold Value… …Formulate a solution Suitability To increase the suitability of the ''formulate solution" SubjectiveEstimate Accuracy To increase the accuracy of "estimate" Subjective… … … …Formulate RFP response Reliability To increase the reliability of "formulate RFP response" Required Uptime 10 hours … … … …A function of the
RFP process
The quality characteristic selected for “Formulate RFP response” function
The metric for the specified softgoal
The softgoal specified for the reliability
characteristic
The threshold value for the
specified metric
Fig. 5.15. Function Measurement Model Template
A function of the RFP process
The output from the “formulate RFP response”
function
The metric for the specified softgoal
The softgoal specified for the reputable
characteristic
The threshold value for the
specified metric
Function Input/Output Quality Characteristic Softgoal Metric Threshold Value… … … … … …Formulate a solution RFP Relevancy To increase the relevancy of the "RFP" Source of data Prospect ClientFormulate a solution Solution Completeness To increase the completeness of the "solution" Sections of Solution Document 100%Estimate Estimate Accuracy To increase the accuracy of "estimate" Estimation method Estimation Tool… … … … … …Formulate RFP response RFP Response Reputable To increase the reputability of the "RFP response" Source of data Project Management Tool… … … … … …
Fig. 5.16. Input & Output Measurement Template
softgoal for an input or output softgoal of a function of the selected business
process.
Function Human Resource Quality Characteristic Softgoal Metric Threshold Value… … … … … …Formulate a solution Solution Architect Qualification To ensure the resource has necessary qualification to perform the task Degree ITEstimate Solution Architect Qualification To ensure the resource is certified to perform the task Degree IT… … … … …Formulate RFP response Project Manager Certification To ensure the resource is certified to perform the task Certification PRINCE II… … … … … …A function of the
RFP process
The resource for the “formulate RFP response”
function
The metric for the specified softgoal
The softgoal specified for the certification
characteristic
The threshold value for the
specified metric
Fig. 5.17. Human Resource Measurement Template
Figure 5.17 presents the third template which is used to capture quality
metrics and their relevant threshold values for the softgoals identified for
154 5
the the human resources of the selected process. Each row in the table
presents a metric for a softgoal for a human resource quality characteristic
of a function of the selected business process.
Function Non-Human Resource Quality Characteristic Softgoal Metric Threshold Value… … … … … …Formulate a solution UML Tool Suitability To increase the suitability of the "UML Tool" Supported UML diagrams Use case, Sequence diagramEstimate Estimation Tool Accuracy To increase the suitability of the "Estimation Tool" Subjective… … … … … …Formulate RFP response Project Management Tool Reliability To improve the reliability of the "Project Management Tool" Required Uptime 10 hours… … … …A function of the
RFP process
The non-human resource for the “formulate RFP
response” function
The metric for the specified softgoal
The softgoal specified for the reliability
characteristic
The threshold value for the
specified metric
Fig. 5.18. Non-Human Resource Measurement Template
Figure 5.13 presents the fourth template which is used to capture quality
metrics and their relevant threshold values for the softgoals identified for
the the non-human resources of the selected process. Each row in the table
presents a metric for a softgoal for a non-human resource quality character-
istic of a function of the selected business process.
5.3.4.2 Action Taking Stage - Phase II
The purpose of this stage is to perform the activities identified for phase II
of the action taking stage.
As described in Section 5.3.3, the action plan for phase II is based on the
PRCA technique presented in Section 4.5.2. This section complements the
PRCA methodology by providing some guidelines on how to perform each
procedural step of the PRCA technique. The PRCA technique proposed by
this research provides a step-by-step procedure to identify the root causes of
a quality issue for an instance of a process. In order to trace a quality issue
back to its root causes for an instance of a business process, the correlations
between softgoals that are modelled in a softgoal correlation model for the
process12 are used.
12 Refer to Section 4.4.3 for further details on the softgoal correlation model.
5.3 Action Research Plan 155
Softgoal Metric Value SatisfiedTo improve the accuracy of the estimate etsimation duration 10 hours YesTo improve the experience of the Software Engineer software engineer eperience 1 year No… … … …
The softgoal being evaluated
The metric that is defined to measure softgoal satisfaction
The software engineer who was responsible for
estimation has only 1 year of estimation experience
This softgoal is not satisfied because the
threshold value for this metric was “>2 years”
Fig. 5.19. Process Root Cause Analysis (PRCA) Template
The researcher will organise a series of workshops to conduct root cause
analysis for the quality issue that is being investigated. A step-by-step pro-
cedures provided by the PRCA technique (presented in Section 4.5.2) will
be followed. The researcher will invite the appropriate participants for each
workshop based on the information/data that is required to be gathered.
Figure 5.19 presents a template that is provided to record the results of the
investigation as instructed in the third step of the PRCA technique13. Each
row in the template presents the value of a metric for a traced softgoal that
is being evaluated and the results of that evaluation; i.e. whether the metric
has met the defined threshold value to satisfy the softgoal. It is envisaged
that up to 4 workshops of 2 hours each is required to complete this step.
5.3.5 Evaluation
The purpose of this stage is to evaluate the consequences of the actions
taken in the previous stage.
As discussed in Section 3.6, the usability, usefulness, and scalability of
the artifacts designed during the design science phase of this study will
be evaluated by conducting action research14. To ensure the rigor of the
evaluation phase of this study15, a set of evaluation objectives are developed
and presented in this section. These objectives, with respect to the artifacts
developed during the design phase of this study, are:
13 The third step is to evaluate the traced softgoal and record the results (see Section 4.5.2).14 Refer to guideline 3 - design evaluation [2] described in Section 3.6.15 Refer to guideline 5 - research rigor [2] described in Section 3.6.
156 5
• Quality model:
– Evaluate the applicability of the quality characteristics defined for
four quality dimensions (function quality dimension, input & output
quality dimension, human resource quality dimension, and non-human
resource quality dimension). The quality model for a business process
which consists of the quality characteristics for the four quality dimen-
sions of the business process was presented in Section 4.3.2.1. Whilst
the quality characteristics defined for the four dimensions of a busi-
ness process were built based on the quality models in related areas16,
the applicability of the quality characteristics to the business process
dimensions needs to be evaluated during this stage. Accordingly, the
evaluation objective here is to confirm the relevance and appropriate-
ness of each quality characteristic with respect to its quality dimen-
sion. For example, evaluate if reputability is relevant or appropriate
for the the input & output quality dimension.
– Evaluate the usability and scalability of the QoBP methodology and
templates to identify and capture the quality characteristics for four
quality dimensions of the selected business process. This evaluation
objective ensures that the QoBP methodology (Section 4.4.6.3) and
the supporting templates (Section 5.3.4.1.3) scale well and are usable
for large business processes where a large number of functions, data
(inputs & outputs) and resources (human & non-human resources are
involved.
• Softgoal model:
– Evaluate the applicability of the softgoal model of the QoBP frame-
work. The objective of this evaluation is to ensure that the goal-
oriented approach adopted in this research is a relevant and appro-
priate approach in coping with the abstract and informal nature of
non-functional requirements in the form of quality characteristics.
16 Refer to Section 4.3.1 for further details on how the quality characteristics defined for eachquality dimension of the business process is built on the quality models in relevant areas.
5.3 Action Research Plan 157
– Evaluate the usability of the softgoal model of the QoBP framework
in refining abstract and informal quality characteristics. This evalu-
ation objective ensures that the quality characteristics of a business
process (the quality model of a business process) are represented and
reasoned about by softgoals defined in a softgoal model.
– Evaluate the practicality and scalability of the QoBP methodology
and the templates to identify and capture softgoals for the identified
quality characteristics for the selected business process. This evalua-
tion objective ensures the QoBP methodology (Section 4.4.6.4) and
the supporting templates (Section 5.3.4.1.4) scale well and are practi-
cal for large business processes where large number of functions, data
(inputs & outputs) and resources (human & non-human resources are
involved.
• Softgoal correlation model:
– Evaluate the practicality and scalability of the QoBP methodology
and the templates to capture the correlations between identified soft-
goals. This evaluation objective ensures that the QoBP methodology
(Section 4.4.6.5) and the supporting templates (Section 5.3.4.1.5) scale
well and are practical for a large business processes where large num-
ber of functions, data (inputs & outputs) and resources (human &
non-human resources) are involved.
• Measurement model:
– Evaluate the practicality and scalability of the QoBP methodology,
and the templates to identify and capture quality metrics for the
identified softgoals. This evaluation objective ensures that the QoBP
methodology (proposed in Section 4.4.6.6) and the supporting tem-
plates (Section 5.3.4.1.6) scale well and are practical for large business
processes where a large number of functions, data (inputs & outputs)
and resources (human & non-human resources) are involved.
158 5
• QoBP Metamodel:
– Evaluate the validity of the QoBP metamodel (Section 4.4.5.2) in
producing a quality-aware business process. As described in Sec-
tion 4.4.5.2, the QoBP metamodel is an extension to the EPC meta-
model that introduces additional concepts to capture those entities
relevant to the quality of a business process. This evaluation objec-
tive ensures that the QoBP metamodel captures the necessary entities
to produce a quality-aware business process.
• PRCA Technique:
– Evaluate the comprehensiveness of the PRCA approach by evaluating
whether the PRCA approach provides the investigators with the abil-
ity to identify the sequence of events leading to a cause of a quality
issue.
– Evaluate the context-awareness of the PRCA approach by evaluating
whether the PRCA approach provides the investigators with the con-
text required to conduct corrective actions.
– Evaluate whether the PRCA approach provides a systematic method-
ology that provides a step-by-step and consistent approach to conduct
an investigation.
– Evaluate whether the PRCA approach is easy to learn and is easy to
use.
The researcher will organise a series of workshops with key participants
to thoroughly evaluate the outcome of the action research based on the
above objectives. The researcher will use the questionnaire provided in Ap-
pendix B.5 to guide the evaluation process. This questionnaire is created
based on the above objectives. It is envisaged that up to 4 workshops of 4
hours each is required to complete this step.
5.4 Action Research Cycle Report Structure 159
5.3.6 Specifying Learning
The purpose of this step is to identify the lessons learned during the action
research cycle. The evaluation results produced during the last stage will as-
sist the discovery of the lessons learned. During this stage, the researcher will
organise a series of workshops with key stakeholders to reflect on the evalu-
ation results. The lessons learned and possible enhancements to the QoBP
framework and PRCA technique will be identified during these workshops.
The enhancement opportunities identified for artifacts being evaluated will
be used to enhance the relevant artifacts. It is envisaged that up to 2 work-
shops of 4 hours each is required to complete this step.
5.3.7 Closure
During this last stage of the action research, the researcher will organise an
informal meeting to express her appreciation to the key stakeholders con-
tributing to this collaborative project.
5.4 Action Research Cycle Report Structure
Each action research cycle will yield an individual report which is presented
in the next three chapters of this thesis. Each report contains:
• A short description about the host organisation
• The justification for choice of the organisation
• An outline of the action research cycle
• An outline of the reflection on the action research cycle and the subse-
quent re-design
• A summary of the action research cycle
160 5
Extra documentation, and notes from the meetings and workshops for
each case are presented in the relevant Appendix.
5.5 Summary
This chapter contributes to the quality and rigor of the action research be-
ing conducted as part of this study by providing a comprehensive action
research protocol. The criteria for selecting a host organisation for the ac-
tion research was presented in Section 5.2. The action research plan which
is based on the procedural steps of QoBP methodology proposed in Sec-
tion 4.4.6 was presented in Section 5.3. The guidelines for the procedures
related to organisation visits and templates to use during the various ac-
tivities were also presented in Section 5.3. The format for presenting the
outcome of each action research cycle was presented in Section 5.4.
The rest of this thesis presents three reports outlining the three action
research cycles conducted in Organisation A, Organisation B, and Organi-
sation C. Chapter 6 presents a report on the first cycle of the action research
that was conducted in Organisation A. The main purpose of the first cycle
was to evaluate the QoBP framework, in particular the quality dimensions
of a business process (quality of functions, quality of inputs&outputs, qual-
ity of human resources, and quality of non-human resources17) in a large
scale project. The lessons learned during this first cycle were used to refine
the framework at the end of the cycle. Chapter 7 presents a report on the
second cycle of the action research which took place in Organisation B with
the aim to evaluate the refined QoBP framework. The lessons learned dur-
ing this cycle again were used to improve the QoBP framework. Chapter 8
presents a report on the third cycle of the action research which took place
in Organisation C to evaluate the refined version of the QoBP framework,
as well the PRCA technique proposed in Section 4.5.2.
17 Refer to Section 4.3.2 for further details on the quality dimensions.
6
First Action Research Cycle
6.1 Introduction
This chapter is a report on the first action research cycle conducted in a
large Australian organisation in the financial sector - Organisation A. As
discussed in Chapter 3, the applicability, usability, usefulness, and scalabil-
ity of the artifacts designed during the design science phase of this study
will be evaluated by conducting action research. Combining a design-based
research approach with an action research methodology is a useful way to
create business knowledge that is both relevant (for both practice and the-
ory) and rigorous [32] (see Section 3.2). As outlined in Section 3.5, three ac-
tion research cycles have been conducted within three large organisations to
evaluate the artifacts that were developed during the design science phase
of this research (these artifacts were presented in Chapter 4). The arti-
facts that were evaluated in the first action research cycle are: the QoBP
framework (Sections 4.3, 4.4.5.2, and 4.4.5.2), the QoBP metamodel (Sec-
tion 4.4.5.2), and the QoBP methodology (Section 4.4.6). In particular, the
aim was to evaluate these artifacts in a reasonably large scale project with
a complex business process.
The action research conducted in Organisation A was based on the key
principles of action research as presented in Chapter 3, and the action re-
search protocol presented in the previous chapter (Chapter 5). The data
captured and the models built during this cycle are presented either in the
relevant sections of this chapter or Appendix C.
162 6
Section 6.2 presents a short description of Organisation A, followed by
Section 6.3 which describes the justification for choosing Organisation A
as the host for the first cycle of the action research. A summary of the
action research cycle stages in Organisation A is presented in Section 6.4.
A reflection on the lessons learned from the first action research cycle and
the enhancements made to the framework as a result were presented in
Section 6.5.
6.2 Description of the Organisation
Organisation A, a publicly listed company, is one of the Australia’s top
20 companies and a leader in banking, insurance, investment and superan-
nuation with a focus on retail customers and small to medium businesses.
Corporation A’s market capitalisation is more than $14 billion and is owned
by more than 300,000 shareholders. The current corporations assets are $98
billion and has more than 7 million customers.
The corporation provides a range of banking and insurance products di-
rectly to customers through an extensive branch and agency network, call
centre operations, on-line facilities, and through intermediaries and corpo-
rate partners. The corporation’s insurance division provides personal insur-
ance products such as home and contents and personal effects cover, motor
and boat, compulsory third party insurance, workers compensation and a
range of commercial insurance products suitable to the small to medium
business market. The corporation’s banking division consists of two sub-
divisions of retail and business banking. The corporation’s investment man-
agement division is responsible for the wholesale investment management
activities of the corporation. Organisation A has a well established Business
Process Management (BPM) division which is led by the Business Process
Manager who is expert in the area. A large number of business processes
(several thousands) have been modelled by this division.
The justification for choosing Organisation A as the host for the first
cycle of the action research is presented in the next section.
6.3 163
6.3 Justifications for the Choice of the Organisation
This section presents the justification for choosing Organisation A as the
host for the first cycle of the action research. As outlined in Section 5.2,
to gain maximum benefit from the action research phase, certain criteria
for the selection of an appropriate host organisation must be met. The
selection criteria that were provided in Section 5.2 were used to evaluate if
Organisation A is an appropriate organisation to host the first cycle of the
action research. After the initial contact with Organisation A and discussing
the purpose of the engagement, it was clear that Organisation A was an
appropriate candidate for hosting the first cycle of the action research. This
organisation was chosen to participate in the first cycle of the action research
for the following reasons:
• Criterion 1 - It was important for the organisation to have an apprecia-
tion for BPM and commitment to BPM principles and practices. Organ-
isation A is a large organisation, with a division dedicated to Business
Process Management. The BPM division within Organisation A has a
well established business process framework, supporting tools and stan-
dards. The BPM division within Organisation A is led by the Business
Process Manager who is extremely knowledgable in the area and he ac-
tively contributes to the BPM community of Australia. A variety of dif-
ferent business processes which could benefit from the QoBP framework
were available to choose from. It was important to be able to choose a
reasonably large business process for this cycle of the action research.
• Criterion 2 - It was important for the organisation to have an appre-
ciation for research in the area and preferably a prior relationship with
the BPM research center within Queensland University of Technology.
The Business Process Manager who leads the BPM division has been
involved with other collaborative works with the QUT BPM center and
is very well aware of the QUT BPM center research activities, rules and
regulations.
• Criterion 3 - It was important for the organisation to have an ap-
preciation for quality aware BPM and be keen to introduce the quality
164 6
framework proposed by this thesis to their BPM practice. The key stake-
holders were interested in the research. They acknowledged the limitation
of the BPM framework being practiced by the organisation in supporting
quality-aware business processes. Therefore, they were very keen to par-
ticipate in this action research and take part in exploring the proposed
QoBP framework and were familiar with collaborative projects of this
nature involving Queensland University of Technology.
• Criterion 4 - Organisation A was located in close proximity which made
accessibility to its resources and people easier to the researcher.
Next section presents a summary of the different stages of the action
research cycle in Organisation A.
6.4 Action Research Cycle
This section presents a detailed report on the action research cycle within
Organisation A. The action research cycle was conducted according to the
action research plan provided in Section 5.3 which consists of seven stages:
initial meeting, diagnosis, action planning, action taking, evaluating, speci-
fying learning, and closure. The action research conducted in Organisation
A was a formal collaborative project where the Business Process Manager
(the practice lead of the BPM division) was the key stakeholder and main
industry advisor.
The researcher closely followed the action research plan presented in
Section 5.3. An outline of the different stages of the action research cycle
in Organisation A is presented in the following sub-sections. Section 6.4.1
presents a summary of the initial meeting with the key stakeholders of Or-
ganisation A. An outline of the outcome of the diagnosis stage is presented
in Section 6.4.2. Section 6.4.3 presents a summary of the action planning
stage with the key stakeholders of Organisation A. A detailed outline of the
activities performed during the action taking stage is presented in Section
6.4.4. Section 6.4.5 presents the details on the evaluation stage of the ac-
6.4 165
tion research cycle as well as the outcome of this evaluation. An outline of
the lessons learned during this action research cycle is presented in Section
6.4.6. A briefing of the last stage of the cycle is presented in Section 6.4.7.
6.4.1 Initial Meeting
This section presents a short summary of the first stage of the cycle which is
the initial meeting with the key stakeholders in Organisation A. During this
stage, the researcher organised a meeting with the Business Process Man-
ager (the key stakeholder in Organisation A) to discuss this collaborative
opportunity in detail. A summary of the research topic and action research
approach was sent to the invitees prior to the meeting1. During the initial
meeting the researcher briefly described the QoBP framework proposed by
this thesis, the action research methodology in general, and the action re-
search protocol for this specific collaboration. By the end of the session, the
Business Process Manager was aware of the engagement plan during the cy-
cle and the commitment required through the whole life cycle of the project.
Next section presents a brief summary of the next stage of the action
research cycle - diagnosis.
6.4.2 Diagnosis
The purpose of this phase was to identify a business process that will ben-
efit from the QoBP framework. During this stage, as guided by the action
research protocol presented in Section 5.3.2, the researcher conducted two
informal meetings with the Business Process Manager. During these meet-
ings the researcher described the purpose of the diagnosis phase of the action
research cycle. In order to identify a candidate process, the researcher de-
scribed how the host organisation will benefit from introducing the QoBP
framework to their BPM practice.
The Business Process Manager proposed a project that was underway
and could be of benefit to this action research. The project was initiated as
1 A copy of the summary is presented in Appendix B.4.
166 6
part of the organisation’s engagement in a merger with an insurance com-
pany. Financial organisations are increasingly experiencing the need for im-
proving efficiency and quality of their processes to enhance customer experi-
ence. In this context, a major project was underway to identify improvement
opportunities for the motor vehicle insurance claim process, specifically in
conformance with the existing claim processes. The scope of this specific
project was limited to the first two phases of the BPM life cycle, analy-
sis and design2 for the claim intake process of the motor vehicle insurance
process. Accordingly, an in-depth understanding of the detailed process re-
quirements was needed during the analysis stage, followed by engineering
the overall process structure (identification and modelling of the functions,
inputs & outputs, human and non-human resources of the process) based
on the requirements from the analysis phase. The expected deliverable of
this project was a business process model for the claim intake process.
From the initial descriptions that were received3, this project was a suit-
able case for the first cycle of the action research. The complexity and size of
the process, in terms of functions, inputs-outputs, and resources, promised
a substantial amount of data collection. This was necessary for the proper
evaluation of the QoBP framework, specifically the quality dimensions of
the process and the practicality of the supporting methodology. The Busi-
ness Process Manager was also very keen to improve the quality of the claim
intake process. Incorporating the QoBP framework proposed by this study
to produce a quality-aware claim intake process model was very promising.
The following section presents the next stage of the action research cy-
cle which is concerned with the planning of activities required to create a
quality-aware claim intake process.
6.4.3 Action Planning
The purpose of this phase was to define the activities required to create
a quality-aware claim intake process using the QoBP framework. The re-
2 Refer to Section 2.2.3 for detailed description on analysis and design phases of the BPM lifecycle.
3 Refer to Section 6.4.4.1 for the claim intake process description.
6.4 167
searcher conducted an informal meeting with the Business Process Manager
to describe the QoBP methodology (Section 4.4.6) and the activity plan that
was based on the procedural steps of this methodology. Ph ase Sub-A ctivity Engagem ent Type D uration A ction Research Cycle – A ction Taking A nalyse the Process W orkshop 4 hou rs Create Business Process M odel W orkshop 16 ho urs Create Q uality M o del W orkshop 16 ho urs Create Softgoal M o del W orkshop 16 ho urs Create Correlatio ns M o del N one 4 hou rs Create M easurem ent M o del W orkshop 8 hou rs Prepare Pro ject Rep ort N one 40 ho urs
Fig. 6.1. Plan for the Action Taking Phase
Figure 6.1 presents an outline of the activity plan scheduled for the next
stage of the action research cycle - action taking. An outline of the next
stage of the action research cycle in Organisation A is presented below.
6.4.4 Action Taking
The purpose of this stage was to perform the activities identified during the
action planning stage. The researcher organised a series of workshops with
the key stakeholders according to the action plan. The researcher followed
168 6
the action research protocol, presented in the previous chapter, for each
workshop during this stage.
An outline of the activities performed during this stage is presented in
this section in the following order. Section 6.4.4.1 presents an outline of
the first step in which the requirements for the claim intake process were
analysed. Section 6.4.4.2 presents the claim intake business process model
created during the second step. The quality model created for the claim
intake process during the third step is presented in Section 6.4.4.3. Section
6.4.4.4 presents the softgoal model for the claim intake process which was
created during the fourth step. The correlation model for the claim intake
process created during the fifth step is presented in Section 6.4.4.5. Finally,
Section 6.4.4.6 presents the measurement model for the claim intake process
created in the last step of the action taking phase.
6.4.4.1 Step 1 - Analyse the Business Process
The purpose of the first step was to analyse the claim intake process goals,
the claim intake process environment, the organisation structure, and the
claim intake process quality requirements. For this step, the researcher or-
ganised a workshop with the Business Process Manager and claim intake
process Subject Matter Experts (the key stakeholders) following the proce-
dures and guidelines provided by the action research protocol presented in
Chapter 5.
During the workshop, the functional and quality (non-functional) re-
quirements of the claim intake process were elicited, taking account of the
organisation’s strategy, goals and structure. The researcher used the tech-
niques and guidelines described in Section 5.3.4.1.1 to elicit these require-
ments. The deliverable of this phase was the functional and quality (non-
functional) requirements description of the claim intake process. A brief
overview of this description is presented below, followed by a summary of
the quality requirements for the claim intake process.
6.4 169
6.4.4.1.1 Overview of the Claim Intake Process
The claim intake process is the process of lodging a car insurance claim by
a customer involved in a motor incident. A customer initiates the process
by calling the claim center and requesting to lodge a claim. It is crucial for
a customer to provide necessary information to be identified as the autho-
rised person to lodge the claim. A customer usually can be authenticated by
providing details such as name, address, date of birth and policy number.
After customer authentication, the customer is asked to provide details of
the incident and the loss she is lodging a claim for. At this stage, the claim
is lodged and further assessments are required to ensure the validity of the
claim. The incident needs to be validated against the customer motor vehi-
cle insurance policy to insure the incident event is covered under the policy.
The liability also needs to be assessed against the information provided.
After completion of the assessment, details of the third party and their in-
volvement are captured. The excess is then assessed based on the customer’s
policy. After assessing the excess, the assessment of the vehicle repair path
starts based on the gathered information such as whether the vehicle is
drivable, product information, towing arrangements etc. The next step in-
volves an assessment of additional benefits within the policy limit such as
hire car or emergency repairs. At this stage, information about the process,
based on the collected information, is communicated to the customer. The
claim intake process is finalised by determining the claim ownership and an
indication of how to proceed with the claim.
It was important for Organisation A to provide a seamless, end to end
claims experience with structured information collection and management.
The summary of the quality requirements elicited during this stage are as
follows:
• Consistency and acceptable response time to calls,
• Rapid identification of the policy,
• Accurate validation of the policy and customer details,
170 6
• Efficient and effective collection of information,
• Value the customer,
• Understanding the customer,
• Ease of understandability of the claim intake process to customer,
• High availability of the claim intake process for customer, and
• A reliable claim intake process;
Having gathered and documented the functional and quality require-
ments of the claim intake process, the next step was to start the design
phase and model the claim intake process based on the functional require-
ments defined above. This step is presented in the following section.
6.4.4.2 Step 2 - Create Business Process Model
The purpose of this step was to model the claim intake process using a busi-
ness process modelling language4. As described in Section 5.3.4.1.2, during
this step the researcher conducted three workshops with the Business Pro-
cess Manager and claim intake process Subject Matter Experts to model
the overall structure of the claim intake process based on the functional
requirements defined in the previous step. During the workshops, the re-
searcher followed the methodology and guidelines provided by the action
research protocol, presented in Section 5.3.4.1.2, to identify: (1) activities
of the claim intake process, (2) specification of human resources involved
with activities and their role within the organisation, (3) specification of
non-human resources (such as computer systems, printers, projectors etc)
required for the activities, and (4) the specification of data & information
associated with the activities. The deliverable of this step was an EPC
model for the claim intake process which is presented in figure 6.25. EPC
4 Refer to the QoBP methodology presented in Section 4.4.6 for further details on this step.5 The researcher was playing a more passive role during these workshops and her role wasjust to ensure that four dimensions of the claim intake process (functions, inputs & outputs,
6.4 171
was chosen because it was the preferred business process notation of the
participating organisation.
The claim intake process consists of 12 functions (see Figure 6.2). The
claim intake process starts with obtaining policy details including policy
number, validating the caller by retrieving policy details, and checking
whether she is authorised to lodge a claim (obtain policy details and val-
idate caller is authorised to lodge function). Once the caller is validated,
the policy needs to be checked to match the details of the vehicle involved
in the accident (validate policy function). After that, the incident and loss
details are captured (capture incident details). The next step is to validate
if the incident event is covered under the policy (validate incident coverage
function). The liability also needs to be assessed against the information
provided (assess liability function). Upon assessment of the liability, details
and involvement of the third party are captured (capture loss & TP details
function). Then excess is assessed (assess excess function). After assess-
ing the excess, the assessment of the vehicle repair path starts based on
gathered information such as whether the vehicle is drivable, product infor-
mation, towing arrangement etc (assess pathing function). The next step
involves an assessment of additional benefits within the policy limit such
as hire car or emergency repairs (action hire car and towing as appropri-
ate function). Next step is then to add appropriate authorised parties (add
authorised parties function). The information about the process, based on
the collected information, is then communicated to the customer (inform
customer of next steps function). The final step of the claim intake process
is to determine the claim ownership and an indication of how to proceed
with the claim (finalise claim intake function).
Having modelled the claim intake process, the next step was to define a
quality model for the process which is presented in the following section.
human resources and non-human resources) were modelled. The Business Process Managerwas more actively involved in the modelling exercise using their established framework (asmentioned in Section 4.4.6.2, the QoBP framework proposed in this research is not bound toany specific business process modelling methodology or notation).
172 6
New claim is logged
Obtain policy details and
validate customer
Customer validated
Validate policy
Policy validated
Validate incident
coverage Incident
coverage validated
Assess liability
Liability assessed
Capture TP details
TP details captured
Assess excess
Excess assessed
Assess pathingPathing
assessed
Add authorised parties (as
appropriate)Authorised
parties added
Inform customer of
next step
Customer is informed of next steps
V
Outbound contact required
Finalise claim intake
V
End callPotential recovery identified
Potential investigation
required
Claims Processor
Claims Processor
Claims Processor
Claims Processor
Claims Processor
Claims Processor
Claims Processor
Claims Processor
Claims Processor
Claims Processor
Customer Products
Policy Identification
Customer Identification
Policy Identification
Coverage & Policy Extra
Vehicle Information
Incident Details
Coverage & Policy Extra
Capture incident detailsIncident
details captured
Incident Details
Claim Business
Rules
Incident Details
Claim Business
Rules
Vehicle Information
Third Part Property Details
Customer Personal Property Details
Driver Details
Vehicle Information
Coverage & Policy Extra
Incident Details
Claim Business
RulesVehicle
InformationIncident Details
Assessment Details
Claim Identification
Other Parties Details
Vehicle Information
Claim Service
Assessment Details
Incident Details
Third Party Details
Claim Service
Assessment Details
Claim Actions
Action hire car and towing (as appropriate)
Vehicle Information
Coverage & Policy Extra
Assessment Details
Hire car actioned
Claims Processor
Fig. 6.2. Claim Intake Process EPC
6.4 173
6.4.4.3 Step 3 - Create a Quality Model
The purpose of this step was to define a quality model for the claim in-
take process based on the quality requirements defined during the step 1.
During this step, the researcher conducted four workshops with the Busi-
ness Process Manager and the claim intake process Subject Matter Experts
(the key stakeholders) to capture the quality characteristics for the four
business process quality dimensions (functions, inputs-outputs, human re-
sources, and non-human resources). During the workshops, the researcher
followed the methodology and guidelines provided by the action research
protocol, presented in Section 5.3.4.1.3. The outcome of these workshops
was a quality model consisting of the quality characteristics for the four
dimensions of the claim intake process. The four quality dimensions of the
claim intake process are presented below.
Function Quality Dimension
The purpose the first workshop was to identify the quality characteristics of
the function dimension of the claim intake process. It was crucial to ensure
that the quality characteristics being selected were aligned with the quality
requirements defined during the first step (see Section 6.4.4.1). Therefore,
the first exercise was to map the high level quality requirements defined
during the first step to the functions of the claim intake process. As listed
below, this mapping did associate each defined quality requirement to one
or more functions of the claim intake process:
• Requirement 1 - Consistency and acceptable response time to calls
– Function - Obtain policy details and validate caller (authorised to
lodge)
• Requirement 2 - Rapid identification of the policy
– Function - Validate policy
• Requirement 3 - Accurate validation of the policy and customer details
– Function - Validate policy
• Requirement 4 - Efficient and effective collection of information
174 6
– Function - Obtain policy details and validate caller (authorised to
lodge)
– Function - Capture incident details
– Function - Capture loss & TP details
• Requirement 5 - Value the customer
– Function - Obtain policy details and validate caller (authorised to
lodge)
– Function - Inform customer of next steps
– Function - Finalise claim intake
• Requirement 6 - Understanding the customer
– Function - Obtain policy details and validate caller (authorised to
lodge)
– Function - Capture incident details
– Function - Inform customer of next steps
– Function - Finalise claim intake
• Requirement 7 - Ease of understandability of the claim intake process to
customer
– Function - Obtain policy details and validate caller (authorised to
lodge)
– Function - Capture incident details
– Function - Inform customer of next steps
– Function - Finalise claim intake
• Requirement 8 - High availability of the claim intake process for customer
– Function - Obtain policy details and validate caller (authorised to
lodge)
– Function - Validate policy
– Function - Capture incident details
– Function - Validate incident coverage
– Function - Assess liability
– Function - Capture loss & TP details
– Function - Assess excess
6.4 175
– Function - Assess pathing
– Function - Action hire car and towing (as appropriate)
– Function - Add authorised parties (as appropriate)
– Function - Inform customer of next steps
– Function - Finalise claim intake
• Requirement 9 - A reliable claim intake process
– Function - Obtain policy details and validate caller (authorised to
lodge)
– Function - Validate policy
– Function - Capture incident details
– Function - Validate incident coverage
– Function - Assess liability
– Function - Capture loss & TP details
– Function - Assess excess
– Function - Assess pathing
– Function - Action hire car and towing (as appropriate)
– Function - Add authorised parties (as appropriate)
– Function - Inform customer of next steps
– Function - Finalise claim intake
The next exercise was to capture and model the function quality dimen-
sion of the claim intake process. Three templates provided by the action
research protocol (Section 5.3.4.1.3) were used during this workshop to cap-
ture and model the function quality dimension of the claim intake process.
The first matrix, applying the boolean approach value (Yes/No), is pre-
sented in Figure 6.3. The workshop participants rated the function/quality
characteristic combination by determining whether the combination was
important or not (Yes or No). The quality requirements associated to the
functions (listed above) were used to drive the importance of the func-
tion/quality characteristic. This matrix enabled the calculation of both a
function total and a quality characteristic total (Yes count). This provides
a quick way to identify 1) the functions that play an important role in the
quality of the process, and 2) the quality characteristics that are important
176 6
Suitability Accuracy Security Reliability Understandability Learnability Time behavio
ur efficiency Resource utilisation Effectiveness Productivity Safety Satisfaction Robustness Total
Obtain policy details and validate caller (authorised to lodge)Y Y Y Y Y Y Y Y Y Y 10Validate policy Y Y Y Y Y Y Y Y Y Y Y 11Capture incident details Y Y Y Y Y Y Y Y Y Y 10Validate incident coverage Y Y Y Y Y 5Assess liability Y Y Y Y 4Capture loss & TP details Y Y Y Y Y Y Y Y 8Assess excess Y Y Y Y 4Assess pathing Y Y Y Y 4Action hire car and towing (as appropriate) Y 1Add authorised parties (as appropriate) Y Y 2Inform customer of next steps Y Y Y Y Y 5Finalise claim intake Y Y Y Y Y 5Total 12 8 5 9 6 5 4 4 4 4 0 2 6Fig. 6.3. Claim Intake Process - Function Quality Dimension (captured as yes or no)
for the process.
024681012
Fig. 6.4. Claim Intake Process - Functions Quality Rating
In this instance, the functions: validate policy (11), Obtain policy details
and validate caller (10), and Capture incident details (10) scored the high-
6.4 177
est ratings therefore play a more significant role in the quality outcomes for
the claim intake process. This exercise also identified that the functions:
action hire car and towing (1) and add authorised parties (2) play a less
important role in the quality outcomes for the claim intake process. These
results are displayed graphically in Figure 6.4.
0246810
12
Fig. 6.5. Claim Intake Process - Quality Characteristics
The quality characteristics: suitability (12), reliability (9) and accuracy
(8) scored the highest ratings highlighting these characteristics as more im-
portant for this process. This exercise also identified that safety (0) and
satisfaction (2) are less important characteristics for this process. These re-
sults are displayed graphically in Figure 6.5.
The next matrix, in which participants determined the top 3 functions for
each quality characteristics, is presented in Figure 6.6. The quality require-
ments associated to the functions (listed at the beginning of this section)
were used to drive the top 3 functions for each quality characteristics. The
totals obtained for each function by this approach highlight that the func-
178 6
Suitability Accuracy Security Reliability Understandability Learnability Time behavio
ur efficiency Resource utilisation Effectiveness Productivity Safety Satisfaction Robustness Total
Obtain policy details and validate caller (authorised to lodge) 3 3 1 7Validate policy 2 2Capture incident details 3 1 2 2 2 3 2 2 2 2 21Validate incident coverage 1 1 1 3Assess liability 3 2 5Capture loss & TP details 2 3 1 1 3 2 1 3 3 3 22Assess excess 2 1 3Assess pathing 3 3Action hire car and towing (as appropriate) 0Add authorised parties (as appropriate) 0Inform customer of next steps 1 3 1 1 6Finalise claim intake 0Fig. 6.6. Function Quality Dimension (by functions - columns)
tions: capture loss & TP details (22) and capture incident details (21) are
the more important functions for obtaining quality outcomes. Also the func-
tions: action Car hire and towing (0), add authorised parties (0) and finalise
claim intake (0) play a less important role in the quality outcomes for the
claim intake process. These results are displayed graphically in Figure 6.7.
0510152025 Quality Rating by Function
Fig. 6.7. Claim Intake Process - Quality Rating by Functions
6.4 179
The next matrix, in which participants determined the top 3 quality
characteristics for each function, is presented in Figure 6.8. The quality re-
quirements associated to the functions (listed above) were used to drive the
top 3 quality characteristics for each function.
Suita
bility
Accu
racy
Secu
rity
Relia
bility
Unde
rstan
dabil
ity
Learn
abilit
y
Time b
ehav
iour e
fficie
ncy
Reso
urce
utilis
ation
Effec
tiven
ess
Prod
uctiv
ity
Safet
y
Satis
factio
n
Robu
stnes
s
Obtain policy details and validate caller (authorised to lodge) 2 1 3Validate policy 3 1 2Capture incident details 3 2 1Validate incident coverage 3 2 1Assess liability 3 2 1Capture loss & TP details 3 2 1Assess excess 3 2 1Assess pathing 3 2 1Action hire car and towing (as appropriate) 3 2 1Add authorised parties (as appropriate) 1 3 2Inform customer of next steps 2 1 3Finalise claim intake 2 1 3
Total 17 15 3 11 12 1 0 0 3 8 0 0 2
Fig. 6.8. Function Quality Dimension (by rows - quality characteristics)
The totals obtained for each quality characteristic by this approach high-
light that the quality characteristics: suitability (17) and accuracy (15) are
the significant quality characteristics for the claim intake process. Also the
quality characteristics: time behaviour efficiency (0), resource utilisation (0),
safety (0) and satisfaction (0) play a less important role in the quality out-
comes for the claim intake process. These results are displayed graphically
in Figure 6.9.
The following sub-section presents the outcome of the second workshop
conducted to model the input & output quality dimension of the claim in-
take process.
Input & Output Quality Dimension
The purpose of the second workshop was to identify the quality charac-
180 6
024681012141618
Fig. 6.9. Claim Intake Process - Quality Rating
teristics of the input & output dimension of the claim intake process. The
template and rating approach provided by the action research protocol (Sec-
tion 5.3.4.1.3) was used during this workshop to capture and model the input
& output quality dimension of the claim intake process.
The outcome of the second workshop was an input & output-quality ma-
trix presented in Figure 6.10. Each row of this table represents an input or
output for a function of the claim intake process and the columns represent
the quality characteristics of the input & output dimension. Each quality
characteristic was given a rating (between 1 to 5)6 with respect to the input
or output of the function being analysed. By reviewing this matrix, it was
easy to identify the quality characteristics that are important for all inputs
and outputs of the claim intake process (the quality characteristics with a
rating of > 3). For instance, for the customer identification which is an input
to the obtain policy details and validate caller (the first row in Figure 6.10),
almost all the quality characteristics are important (the characteristics with
rating of 5) except security and value added that were rated 3.
6 Refer to Section 5.3.4.1.3 for further details on the rating method used during this step.
6.4 181
`
Function Inputs Outputs Accuracy Objectivity Believability Reputation Accessibility Security Relevancy Value-added Timeliness Completeness
Amount of data
Obtain policy details and validate caller (authorised to lodge) Customer Identfication 5 5 5 5 5 3 5 3 5 5 5Customer Products 4 4 4 5 5 5 5 1 5 5 5Policy Identification 4 4 4 5 5 4 5 3 5 5 5Validate policy Policy Identification 5 5 5 5 5 4 5 3 5 5 5Coverage & policy extras 4 4 4 5 4 4 5 3 5 5 5Vehicle Information (Accessories, etc) 3 3 3 5 3 3 4 1 4 4 4Capture incident details Incident Details (Incident Date, Loss Type, Loss Scenario) 5 5 5 4 5 5 5 4 5 4 4Validate incident coverage Coverage & policy extras 4 4 4 5 4 4 5 3 5 5 5Claim Business Rules (Incident Coverage, Liability, Excess & NCD Impact)
4 4 4 5 5 4 5 5 5 5 5Assess liability Incident Details (Incident Date, Loss Type, Loss Scenario) 5 5 5 5 5 5 5 4 5 4 4
Claim Business Rules (Incident Coverage, Liability, Excess & NCD Impact)5 5 5 5 5 4 5 5 5 5 5
Capture loss & TP details Vehicle Information (Accessories, etc) 3 3 3 4 3 3 4 1 4 4 4Driver Details 3 3 3 4 5 5 5 3 5 5 5Customer Vehicle Details / Damage 4 4 4 4 5 4 5 3 5 4 4Customer Personal Property 1 1 1 4 4 4 4 2 4 3 3Third Party Details 3 3 3 3 5 5 5 4 5 4 4Third Party Vehicle Details / Damage 2 3 3 3 4 4 4 2 4 3 3Third Party Property Details 1 3 3 3 4 4 4 2 4 3 3Other Party Details (witness, authorised parties, etc) 3 4 4 3 3 5 4 2 4 4 4Assess excess Coverage & policy extras 4 4 4 5 4 4 5 3 5 5 5Vehicle Information (Accessories, etc) 4 4 4 5 3 3 4 1 4 4 4Incident Details (Incident Date, Loss Type, Loss Scenario) 5 5 5 4 5 5 5 4 5 4 4
Claim Business Rules (Incident Coverage, Liability, Excess & NCD Impact)5 5 5 5 5 4 5 5 5 5 5
Fig. 6.10. Claim Intake Process - Input & Output Quality Dimension
The following sub-section presents the outcome of the third workshop
conducted to model the human resource quality dimension of the claim in-
182 6
take process.
Human Resources Quality Dimension
The purpose of the third workshop was to identify the quality character-
istics of the human resource dimension of the claim intake process. The
template and rating approach provided by the action research protocol (Sec-
tion 5.3.4.1.3) were used during this workshop. During the workshop, the
key stakeholders were asked to select a boolean value (Yes/No) in each cell
of the matrix to specify whether a quality characteristic is important for
the human resource allocated to a function.
`
Doma
in Kn
owled
ge
Quali
ficati
on
Certi
ficati
on
Expe
rienc
e
Time M
anag
emen
t
Comm
unica
tion S
kill
Total
Obtain policy details and validate caller (authorised to lodge)
Y Y 2
Validate policy Y Y 2Capture incident details Y Y Y 3Validate incident coverage Y Y Y 3Assess liability Y Y Y 3Capture loss & TP details Y Y Y 3Assess excess Y Y Y 3Assess pathing Y Y 2Action hire car and towing (as appropriate) Y Y 2Add authorised parties (as appropriate) Y 1Inform customer of next steps Y Y 2Finalise claim intake 0
Total 10 0 0 5 0 11
Fig. 6.11. Claim Intake Process - Human Resource Quality Dimension
The outcome of the third workshop was the table presented in Figure
6.11. Each row of this table represents a function of the claim intake pro-
cess and the columns represent quality characteristics of human resource
6.4 183
dimension. Where a quality characteristic is relevant to the function then a
Y (for yes) is present in the appropriate cell. The totals in a row represent
the number of quality characteristics relevant to the function in that row.
For example, the total of 2 for the function validate policy indicates that
2 quality characteristics out of 6 are relevant and important to this function.
By viewing this table it was easy for the Business Process Manager to
identify the functions that play an important role in the quality of the
process. The column totals are indicators on the relevancy of each quality
characteristic in the whole process. For example, communications skill has
the highest total (11) which indicates that this quality characteristic is very
important for the process, as it is relevant to every single function of the
process. On the other hand, qualification, which has the lowest total (0),
indicates that it is not of significant importance to this process.
In this instance, the human resource responsible for the functions: cap-
ture incident details (3), validate incident coverage (3), access liability (3),
capture loss & TP details (3), and assess excess (3) scored the highest rat-
ings and therefore play a more significant role in the quality outcomes for
the claim intake process. This exercise also identified that the resources
responsible for the functions: finalise claim intake (0) and add authorised
parties (1) play a less important role in the quality outcomes for the claim
intake process. These results are displayed graphically in Figure 6.12.
The quality characteristics: communication skill (11), and domain knowl-
edge (10) scored the highest ratings highlighting these characteristics as
more important for this process. This exercise also identified that qualifi-
cation (0), certification (0), and time management (0) are less important
characteristics for this process. These results are displayed graphically in
Figure 6.13.
The following sub-section presents the outcome of the fourth workshop
conducted to model the non-human resource quality dimension of the claim
intake process.
184 6
0123
Fig. 6.12. Claim Intake Process - Human Resource Quality Rating
024681012
Fig. 6.13. Claim Intake Process - Quality Characteristics
Non-Human Resources Quality Dimension
The purpose of the fourth workshop was to identify the quality characteris-
tics of the non-human resource dimension of the claim intake process. Three
templates provided by the action research protocol (Section 5.3.4.1.3) were
used during this workshop to capture and model the non-human resource
quality dimension of the claim intake process.
The first matrix, applying the boolean approach, is presented in Fig-
ure 6.14. The key stakeholders rated the non-human resource/quality char-
6.4 185
acteristic combination by determining whether the combination was impor-
tant or not (Yes or No). This allowed both a non-human resource total and
a quality characteristic total to be calculated which provides a quick way
to identify 1) the non-human resources that play an important role in the
quality of the process, and 2) the quality characteristics that are important
for the process.
`
Function ResourceSu
itabil
ity
Accu
racy
Secu
rity
Relia
bility
Unde
rstan
dabil
ity
Learn
abilit
yTim
e beh
aviou
r eff
icien
cyRe
sourc
e utili
sation
Effec
tiven
ess
Produ
ctivit
y
Safet
y
Satis
factio
n
Robu
stnes
s
Total
Obtain policy details and validate caller (authorised to lodge)System A Y Y Y Y Y Y Y Y Y Y 10Validate policy System A Y Y Y Y Y Y Y Y Y Y Y 11Capture incident details System A Y Y Y Y Y Y Y Y Y Y 10Validate incident coverage System A Y Y Y Y Y 5Assess liability System A Y Y Y Y 4Capture loss & TP details System A Y Y Y Y Y Y Y Y 8Assess excess System A Y Y Y Y 4Assess pathing System A Y Y Y Y 4Action hire car and towing (as appropriate) System A Y 1Add authorised parties (as appropriate) System A Y Y 2Inform customer of next steps System A Y Y Y Y Y 5Finalise claim intake System A Y Y Y Y Y 5
Total 12 8 5 9 6 5 4 4 4 4 0 2 6
Fig. 6.14. Claim Intake Process - Non Human Resource Quality Dimension (captured as yesor no)
In this instance, the functions: validate policy (11), Obtain policy details
and validate caller (10), and Capture incident details (10) scored the highest
ratings for the non-human resources and therefore play a more significant
role in the quality outcomes for the claim intake process. This exercise also
identified that the functions: action hire car and towing (1) and add autho-
rised parties (2) play a less important role in the quality outcomes for the
claim intake process. These results are displayed graphically in Figure 6.15.
The quality characteristics: suitability (12), reliability (9) and accuracy
(8) scored the highest ratings therefore highlighting these characteristics as
more important for this process. This exercise also identified that safety
(0) and satisfaction (2) are less important characteristics for this process.
These results are displayed graphically in Figure 6.16.
The next matrix, in which participants determined the top 3 resources for
each quality characteristic, is presented in Figure 6.17. The totals obtained
for each function by this approach highlight that the functions: capture loss
186 6
024681012
Fig. 6.15. Claim Intake Process - Non Human Resource Quality Rating
0
2
4
6
8
10
12
Fig. 6.16. Claim Intake Process - Non Human Resource Quality Characteristics
& TP details (22) and capture incident details (21) are the more important
functions for obtaining quality outcomes. Also the functions: action Car hire
and towing (0), add authorised parties (0) and finalise claim intake (0) play
a less important role in the quality outcomes for the claim intake process.
These results are displayed graphically in Figure 6.18.
The next matrix, in which participants determined the top 3 quality
characteristics for each resource, is presented in Figure 6.19.
6.4 187
`
Function Resource
Suita
bility
Accu
racy
Secu
rity
Relia
bility
Unde
rstan
dabil
ity
Learn
abilit
y
Time b
ehav
iour e
fficien
cy
Reso
urce u
tilisat
ion
Effec
tiven
ess
Produ
ctivit
y
Safet
y
Satis
factio
n
Robu
stnes
s
Obtain policy details and validate caller (authorised to lodge) System A 2 1 3Validate policy System A 3 1 2Capture incident details System A 3 2 1Validate incident coverage System A 3 2 1Assess liability System A 3 2 1Capture loss & TP details System A 3 2 1Assess excess System A 3 2 1Assess pathing System A 3 2 1Action hire car and towing (as appropriate) System A 3 2 1Add authorised parties (as appropriate) System A 1 3 2Inform customer of next steps System A 2 1 3Finalise claim intake System A 2 1 3
Total 17 15 3 11 12 1 0 0 3 8 0 0 2
Fig. 6.17. Claim Intake Process - Non Human Resource Quality Dimension (by rows - qualitycharacteristics)
024681012141618
Fig. 6.18. Claim Intake Process - Non Human Resource Quality Rating
The totals obtained for each quality characteristic by this approach high-
light that the quality characteristics: suitability (17) and accuracy (15) are
the significant quality characteristics for the claim intake process. Also the
quality characteristics: time behaviour efficiency (0), resource utilisation (0),
safety (0) and satisfaction (0) play a less important role in the quality out-
comes for the claim intake process. These results are displayed graphically
in Figure 6.20.
188 6
`
Function Resource
Suita
bility
Accu
racy
Secu
rity
Relia
bility
Unde
rstan
dabil
ity
Learn
abilit
y
Time b
ehav
iour e
fficien
cy
Reso
urce u
tilisat
ion
Effec
tiven
ess
Produ
ctivit
y
Safet
y
Satis
factio
n
Robu
stnes
s
Total
Obtain policy details and validate caller (authorised to lodge) System A 3 3 1 7Validate policy System A 2 2Capture incident details System A 3 1 2 2 2 3 2 2 2 2 21Validate incident coverage System A 1 1 1 3Assess liability System A 3 2 5Capture loss & TP details System A 2 3 1 1 3 2 1 3 3 3 22Assess excess System A 2 1 3Assess pathing System A 3 3Action hire car and towing (as appropriate) System A 0Add authorised parties (as appropriate) System A 0Inform customer of next steps System A 1 3 1 1 6Finalise claim intake System A 0
Fig. 6.19. Claim Intake Process - Non Human Quality Dimension (by functions - columns)
0
5
10
15
20
25
Fig. 6.20. Claim Intake Process - Quality Rating by Non Human Resources
The next step after creating the quality model for the claim intake pro-
cess is to create a softgoal model, which is presented below.
6.4 189
6.4.4.4 Step 4 - Create Softgoal Model
The purpose of this step was to create a softgoal model for the claim intake
process7.
During this step, the researcher conducted four workshops with the key
stakeholders to capture softgoals for the quality characteristics identified for
the four dimensions (functions, inputs-outputs, human resources, and non-
human resources) of the claim intake process. During the workshops, the
researcher followed the methodology and guidelines provided by the action
research protocol presented in Chapter 5.3.4.1.4.
The outcome of the first workshop was a softgoal model for the function
quality dimension which is presented in Appendix C.1. The softgoal model
for the input & output quality dimension that was created during the second
workshop is presented in Appendix C.2. The softgoal model for the human
resource quality dimension that was created during the third workshop is
presented in Appendix C.3. Finally, the outcome of the fourth workshop
was a softgoal model for the non-human resource quality dimension which
is presented in Appendix C.4.
The following section outlines the next activity conducted during the
action taking stage of the of the action research cycle in Organisation A.
6.4.4.5 Step 5 - Create Softgoal Correlations Model
The purpose of this step was to create a correlation model for the claim
intake process8.
During this step, the researcher followed the methodology, guidelines
and algorithm provided by the action research protocol presented in Sec-
tion 5.3.4.1.5 to create correlations between the softgoals defined in the
previous step. The outcome of this step was a softgoal correlation model for
7 Refer to Sections 4.4.2 and 4.4.6.4 for further details on the softgoal model.8 Refer to Sections 4.4.3 and 4.4.6.5 for further details on the softgoal correlation model.
190 6
the claim intake process which is presented in Appendix C.5.
The following section outlines the last activity conducted during the of
the action taking stage of the action research cycle in Organisation A.
6.4.4.6 Step 6 - Create Measurement Model
The purpose of this step was to create a measurement model for the claim
intake process9. The measurement model contains the measurable attributes
(referred to as quality metrics) that are identified to evaluate softgoals. As
described in Section 4.4.4, this research adopts an approach similar to the
GQM [147] approach in refining softgoals to a set of quality metrics. Each
softgoal is refined into a set of questions and then each question is refined
into a set of quality metrics.
During this step, the researcher conducted four workshops with the key
stakeholders to create a measurement model which contains quality met-
rics required to measure softgoal satisfaction for the softgoal model created
for the claim intake process. The researcher followed the methodology and
guidelines provided by the action research protocol presented in Section
5.3.4.1.6.
The outcome of the first workshop was a measurement model for the
function quality dimension which is presented in Appendix C.6. The mea-
surement model for the input & output quality dimension that was created
during the second workshop is presented in Appendix C.7. The measurement
model for the human resource quality dimension that was created during
the third workshop is presented in Appendix C.8. Finally, the outcome of
the fourth workshop was a measurement model for the non-human resource
quality dimension which is presented in Appendix C.9.
The following section outlines the next step of the action research cycle
in which the outcome of the activities performed during the action taking
9 Refer to Sections 4.4.4, and 4.4.6.6 for further details on the measurement model.
6.4 191
stage was evaluated.
6.4.5 Evaluation
The main purpose of this stage was to evaluate the applicability, usability,
usefulness, and scalability of the QoBP framework used during the action
taking stage to create a quality-aware claim intake process. As outlined
at the beginning of this chapter, this action research cycle was conducted
according to the guidelines provided by the action research protocol that
was presented in Chapter 5. To ensure the rigor of the evaluation phase of
this study10, a set of evaluation objectives were developed and presented
in Section 5.3.5. The action research protocol also provided a questionnaire
that was created based on these evaluation objectives11.
During this step, the researcher conducted four workshops to evaluate
the outcome of the action research with the Business Process Manager and
the claim intake process Subject Matter Experts (the key stakeholders). The
main purpose of the evaluation stage of the action research cycle was ex-
plained to the key workshop participants at the beginning of the workshop
series. The questionnaire provided by the action research protocol was used
to guide the discussions during the workshops. The researcher followed the
three communication behaviours recommended by [184] to ensure that each
evaluation objective was communicated effectively.
The outcome of the evaluation workshops with respect to the evaluation
objectives include:
• Quality model:
– The applicability of the quality characteristics defined for the four
quality dimensions (function quality dimension, input & output qual-
ity dimension, human resource quality dimension, and non-human re-
source quality dimension) of the quality model was confirmed. The
10 Refer to guideline 5 - research rigor [2] described in Section 3.6.11 This questionnaire is provided in Appendix B.5.
192 6
objective here was to validate that the quality characteristics for four
dimensions are relevant and applicable to business processes. While
these quality characteristics12 were defined based on an extensive lit-
erature review in related areas13, it was crucial to evaluate their appli-
cability to a business process in a real world scenario. The relevancy
and the appropriateness of each quality characteristic with respect to
its quality dimension was reviewed during the evaluation workshops
and was acknowledged by the workshops participants. Comments from
workshop participants include: “...most of the quality characteristics
were relevant and appropriate to the claim intake process, except the
safety characteristic that was not applicable...having said that, this
characteristic might be relevant and applicable to the other processes
where safety could be of importance...”.
– The usability and scalability of the QoBP methodology and the sup-
porting templates (provided in Section 5.3.4.1.3) to identify and cap-
ture the quality characteristics for each quality dimension of the se-
lected business process was reviewed and evaluated. The usability and
scalability of the QoBP methodology and the supporting templates
was confirmed for all dimensions except for the input & output dimen-
sion. It was acknowledged that “...the rating of the quality character-
istics for a large number of inputs and outputs was tedious and time
consuming...”. It was discussed how the relationship between functions
and their inputs and outputs was useful for rating the importance of
the input and output characteristics for that function. For example
if accuracy was selected for a function as a desirable quality char-
acteristic, it was implied that intrinsic quality characteristics (such
as accuracy, objectivity, believability, and reputation) were important
for the inputs and outputs of that function. It was also discussed how
“...the methodology could be improved by using implied relationships
to derive the quality characteristics for inputs & outputs and even
non-human resources...”.
12 Refer to Section 4.3 for further details on four quality dimensions of a business process.13 Refer to Section 4.3.1 for a summary of this literature review.
6.4 193
• Softgoal model:
– The applicability of the softgoal model of the QoBP framework was
confirmed by the workshop participants. It was acknowledged that
the goal-oriented approach adopted in this research is a relevant and
appropriate approach in coping with the abstract and informal nature
of non-functional requirements in the form of quality characteristics.
Comments from the Business Process Manager confirming the appli-
cability of the softgoal model include: “...documenting the original
requirements in the form of quality characteristics and then into a set
of softgoals helped make the original quality requirements more for-
mal and concrete...this exercise helped us come up with metrics that
were aligned with our quality requirements...”.
– The practicality and scalability of the QoBP methodology and the
supporting templates (provided in Section 5.3.4.1.4) to identify and
capture softgoals for the identified quality characteristics of the claim
intake process was confirmed. This evaluation objective was met, as
the key stakeholders acknowledged that the QoBP methodology (pro-
posed in Section 4.4.6.4) and supporting templates (presented in Sec-
tion 5.3.4.1.4) scaled well and were practical for creating a softgoal
model for the claim intake process which is a reasonably large busi-
ness process. After reviewing the softgoal model of the claim intake
process, it was recommended to review the softgoal model for a few
more business processes to determine whether it is practical to create
a set of generic softgoals for all the quality characteristics that can be
used as starting point in future cases. Comments from the workshop
participants reflects this: “...the provided pattern to specify a softgoal
was certainly useful, as it was helpful in framing the softgoals in a
consistent way...it would be more practical if you could start with a
set of generic softgoals instead of defining them from scratch...”.
• Softgoal correlation model:
– The practicality and scalability of the QoBP methodology and the
supporting templates (provided in Section 5.3.4.1.5) to capture the
194 6
correlations between identified softgoals was reviewed during the eval-
uation workshops. It was acknowledged that the scalability of the
QoBP methodology and the supporting templates could be an issue
for larger business processes. It was discussed that as the correlations
are modelled based on a specific algorithm, a tool could be developed
to automate the creation of the softgoal correlation model for a busi-
ness process. Comments from the Business Process Manager include:
“... automation of this step would be useful to help reduce the time
taken...”.
• Measurement model:
– The practicality and scalability of the QoBP methodology and the
supporting templates14 to create a measurement model was confirmed.
It was also acknowledged that the goal-question-metric approach was
very effective in refining each softgoal to a set of quality metrics: “...the
goal-question-metric approach was useful as it provided a structured
way to identify metrics...after learning the approach, it was easy to
follow...”.
• QoBP Metamodel:
– Validity of the QoBP metamodel proposed in Section 4.4.5.2 in pro-
ducing a quality-aware business process was confirmed. This objective
was met, as it was acknowledged that the QoBP metamodel captures
the necessary entities to produce a quality-aware business process.
Comments from the Business Process Manager include: “...the map-
ping of quality characteristics to softgoals and metrics gave us a useful
way of linking our quality requirements to the process model...”.
During the last evaluation workshop it was also acknowledged by the
Business Process Manager that:
14 A set of templates were provided in Section 5.3.4.1.6 as part of the action research protocolto create a measurement model for a business process.
6.4 195
“...this exercise has made me think about our BPM practice and how our
focus has always been on the functional requirements...this exercise helped
us to become more aware of the quality requirements of the claim intake
process...the provided framework was very useful in identifying and model-
ing these requirements...”
“ ...I can foresee how the quality elements defined for the claim intake
process such as quality metrics for human resources can be used during
the process implementation...for example, the quality metrics identified for
the human resources can help in creating position profiles...these position
profiles can then be used to select appropriate staff who match the criteria
specified...”
“...I can see how these quality metrics, when implemented as part of the
process, can add context during the enactment...”
The following section outlines the next step of the first action research
cycle, in which the lessons learned from the action research cycle were iden-
tified.
6.4.6 Specifying Learning
The purpose of this step was to identify the lessons learned during the ac-
tion research cycle. The evaluation results produced during the last stage
strongly influenced the discovery of the lessons learned. During this stage,
the researcher organised a workshop with the key stakeholders to reflect on
the evaluation results described in the previous section. This workshop was
focused on discovering the lessons learned and eliciting the recommenda-
tions for possible enhancements to the QoBP framework. The outcome of
this workshop can be summarised as:
1. It became apparent that there is a relationship between quality of a
function, and the quality aspects of its related entities: inputs & out-
puts, human and non-human resources. It was acknowledged that this
relationship can be used to enhance the QoBP framework, specifically
196 6
the practicality and scalability of the QoBP methodology for larger busi-
ness processes.
2. Having established relationships between quality dimensions (item 1
above) it would be useful to develop a tool that automates some of
the more onerous steps of the QoBP methodology.
3. There are opportunities to improve the QoBP framework, specifically the
practicality and scalability of the QoBP methodology for larger business
processes. Strategies can be introduced to design the collection of in-
formation as efficiently as possible, such as a strategy to identify those
functions that have a high number of quality characteristics and then
develop input/output and resource quality models for these.
Next section presents a summary of the final stage of the action research
cycle with Organisation A - closure.
6.4.7 Closure
This section presents a summary of the last stage of the action research in
Organisation A. During this last stage of the action research, the researcher
organised an informal meeting to express her appreciation to the key stake-
holders contributing to this collaborative project.
6.5 A Reflection on Action Research Cycle and
Re-design
This section presents further reflection on the three enhancement opportuni-
ties identified during the specifying learning stage of the first action research
cycle (Section 6.4.6) and their realisations. The enhancements made to the
artifacts as a result are also presented in this section.
6.5 197
6.5.1 Establish Link Between Quality Dimensions
This section presents the first enhancement opportunity to the QoBP frame-
work. After completing the first cycle of the action research it became
apparent that there is a relationship between function and input/output
dimensions that can be used to enhance the practicality and scalability
of the QoBP methodology (Section 4.4.6). During the specifying learn-
ing workshop (reported in Section 6.4.6), the quality model created for
the claim intake process and notes taken during the relevant workshops
were reviewed by all the workshop participants to establish the relation-
ship between function, input/output and non-human resource dimensions.
Figure 6.21 presents the matrix created from the identified relationships.
This matrix presents the relationships between quality characteristics for
function and input/output dimensions. As it shown in Figure 6.21, each
row represents a function quality characteristic and the columns represent
the input & output quality characteristics. The cells of the matrix therefore
represent a unique function/input-output characteristic relationship where
a ‘Y’ is present indicates the existence of a relationship.
`
Accu
racy
Objec
tivity
Belie
vabil
ity
Repu
tatio
n
Acce
ssibil
ity
Secu
rity
Relev
ancy
Value
-adde
d
Timeli
ness
Comp
leten
ess
Amou
nt of
data
Unde
rstan
dabil
ity
Conc
ise Re
pres
enta
tion
Cons
isten
t Rep
resen
tatio
n
Suitability Y Y Y Y Y Y Y Y YAccuracy Y Y Y YSecurity Y YReliability Y Y Y Y YRobustness Y Y Y Y Y Y Y Y YUnderstandability Y Y Y YLearnability Y Y YTime behavior efficiency Y
Resource utilisation Y Y Y Y Y YEffectiveness Y Y Y Y Y Y Y Y YProductivity Y Y YSafety Y Y Y Y Y Y Y Y YSatisfaction Y Y Y
Input & Output Quality
Characteristics
Function Quality
Characteristics
“Y“ indicates that “accuracy” of input or output does influence the
“suitability” of a function
Fig. 6.21. Function - Input & Output Quality Characteristics Matrix
198 6
It was acknowledged that as non-human resource quality characteristics
are mostly a subset of function quality characteristics a one-to-one rela-
tionship can be established between function quality characteristics and
non-human resource quality characteristics. It means that if accuracy is se-
lected as an important characteristic for a function, it is also an important
quality characteristic for a non-human resource of that function.
The established relationship was used to enhance the QoBP methodology
presented in Section 4.4.6. As a result the third step of the methodology,
which was to create a quality model, was simplified to just two activities in-
stead of four activities. This enhancement was made to address the usability
and scalability limitation of the QoBP methodology to capture the quality
characteristics for the input & output and non-human resource dimensions
of the claim intake process.
The enhanced methodology no longer requires the time consuming task
of capturing the ratings for quality characteristics for the inputs & outputs
and non-human resources. Once the function quality characteristics are se-
lected for a business process, the above matrix (Figure 6.21) can be used
to determine the relevant input & output quality characteristics. The one-
to-one relationship between function quality characteristics and non-human
resource quality characteristics also can be used to determine the relevant
non-human-resource quality characteristics, once the function quality char-
acteristics are selected.
6.5.2 QoBP Automation Tool
This section presents the second enhancement to the QoBP framework
which was the development of the QoBP automation tool. The QoBP au-
tomation tool was developed to automate some of the more onerous steps
of the QoBP methodology. This tool is described in detail in Appendix C.10.
The QoBP methodology (presented in Section 4.4.6), and the action tak-
ing stage of the action research plan presented in Section 5.3.4 are enhanced
6.5 199
as the result of this tool.
Step three of the action taking stage of the action research plan (create
a quality model - Section 5.3.4.1.3) is enhanced as the result of the QoBP
automation tool. Two onerous activities of this step are automated by the
QoBP automation tool to enhance the usability and scalability of the QoBP
methodology.
Quality characteristics of both input/output and non-human resource
dimensions are selected automatically for a process, after the quality char-
acteristics of the function quality dimension are selected for that pro-
cess. These steps are automated based on the relationships defined in Sec-
tion 6.5.1.
6.5.3 Reduce Data Collection for Large Business Processes
This section presents the third enhancement to the QoBP framework. Af-
ter completing the first cycle of the action research it became apparent
that the QoBP framework will benefit from new strategies on efficient
data/information collection. During the specifying learning workshop (re-
ported in Section 6.4.6), the QoBP methodology and supporting templates
used during the action taking stages were reviewed by all the participants
to identify any bottlenecks, and to propose strategies for improvements.
Given, for instance, 13 function quality dimensions and 11 functions in the
claim intake process, there are 143 relationships to be validated.
The proposed strategy was to identify those functions that have a high
number of quality characteristics and develop input/output and resource
quality model for these. Accordingly, obtain policy details and validate cus-
tomer, validate policy and capture incident details were considered with to-
tals of 10, 11 and 12 out of 13. In this case only 52 relationships needed to be
validated which is a significant reduction from the original 143 relationships.
200 6
6.6 Summary of the First Action Research Cycle
This chapter described the first cycle of the action research conducted as
part of this study. During this cycle the validity and applicability of the
quality dimensions of the QoBP framework to a real-world business case
were evaluated. The practicality of the methodology to capture the qual-
ity characteristics for each dimension in a case with a large scale, was also
evaluated. The evaluation of the first action research cycle was presented in
Section 6.4.5. Section 6.4.6 outlined the learning from this cycle. A reflec-
tion on the lessons learned and the enhancements made to the framework
as a result were presented in Section 6.5. The enhancement made to the
QoBP framework include:
• Establishment of links between quality dimensions
• Proposal of a new data collection strategy for large business processes
by providing
• Development of an automation tool to derive the input/output and non-
human resource quality characteristics from the function quality charac-
teristics
These enhancements are evaluated in the two subsequent action research
cycles (Chapters 7 and 8). The objectives of the first action research cycle
were met by enhancing the QoBP framework from the findings described
above after the completion of the first action research cycle.
7
Second Action Research Cycle
7.1 Introduction
This chapter presents a report on the second action research cycle con-
ducted in a large Australian government organisation in the financial sector
- Organisation B. As discussed in Chapter 3, the applicability, usability,
usefulness, and scalability of the artifacts designed during the design sci-
ence phase of this study will be evaluated by conducting action research.
In particular, the aim of this action research cycle was to evaluate the en-
hancements made to the artifacts (the QoBP framework and the QoBP
methodology) based on the lessons learned from the first action research
cycle1.
The action research conducted in Organisation B was based on the key
principles of action research as presented in Chapter 3, and the action re-
search protocol presented in Chapter 5. The data captured and the models
built during this cycle are presented either in the relevant sections of this
chapter or Appendix D. Section 7.2 presents a short description of Organisa-
tion B, followed by Section 7.3 which describes the justification for choosing
Organisation B as the host for the second cycle of the action research. A
summary of the action research cycle stages in Organisation B is presented
in Section 7.4. A reflection on the lessons learned from the second action
research cycle and the enhancements made to the framework as a result
were presented in Section 7.5.
1 Refer to Section 6.4.6 for further details on these enhancements.
202 7
7.2 Description of the Organisation
The corporation (Organisation B), is one of the leading Australian gov-
ernment owned institutional investment managers with over $100 billion in
funds under management. The corporation is predominantly Queensland
based with several offices across Australia and internationally. Organisation
B offers a wide range of solutions such as international properties, infras-
tructure, equities, and fixed interest investments.
The corporation has a division dedicated to BPM which is led by the
Strategy Manager. Although, the BPM initiative at Organisation B is in an
early stage, it has strong executive support and commitment from senior
management and staff. The BPM division is responsible for formulating a
BPM strategy, identifying business improvement opportunities, identifying
company-wide BPM adoption opportunities, and managing & delivery of
business process improvement projects.
The justification for choosing Organisation B as the host for the second
cycle of the action research is presented in the next section.
7.3 Justifications for the Choice of the Organisation
This section presents the justification for choosing Organisation B as the
host for the second cycle of the action research. As outlined in Section 5.2,
to gain maximum benefit from the action research phase, certain criteria
for the selection of an appropriate host organisation must be met. The
selection criteria that were provided in Section 5.2 were used to evaluate
if Organisation B is an appropriate organisation to host the second cycle
of the action research. After the initial contact with Organisation B and
discussing the purpose of the engagement, it was clear that Organisation
B was an appropriate candidate for hosting the second cycle of the action
research. This organisation was chosen to participate in the second cycle of
the action research for the following reasons:
• Criterion 1 - It was important for the organisation to have an apprecia-
tion for BPM and commitment to BPM principles and practices. Organ-
isation A is a large government organisation, with a division dedicated to
7.3 203
Business Process Management. The BPM division, contrary to being in
the early stages of establishment, has a well established business process
framework, supporting tools and standards. The BPM division within
Organisation B is led by the Strategy Manager who is knowledgable in
the area.
• Criterion 2 - It was important for the organisation to have an appreci-
ation for research in the area and preferably a prior relationship with the
BPM research center within Queensland University of Technology. The
Strategy Manager who leads the BPM division has been involved with
other collaborative works with the QUT BPM center and is well aware
of the QUT BPM center research activities, rules and regulations.
• Criterion 3 - It was important for the organisation to have an ap-
preciation for quality aware BPM and be keen to introduce the quality
framework proposed by this thesis to their BPM practice. The key stake-
holders were interested in the research. They acknowledged the limitation
of the BPM framework being practiced by the organisation in support-
ing quality-aware business processes. Therefore, they were very keen to
participate in this action research and take part in exploring the pro-
posed QoBP framework and were familiar with collaborative projects of
this nature involving Queensland University of Technology. They had
just received an approval for a project that could benefit from the QoBP
framework. It was important to be able to choose a business process that
is suitable for this cycle of the action research.
• Criterion 4 - Organisation B was located in close proximity which made
accessibility to its resources and people easier to the researcher.
Next section presents a summary of the different stages of the action
research cycle in Organisation B.
204 7
7.4 Action Research Cycle
This section presents a detailed report on the action research cycle within
Organisation B. The action research cycle was conducted according to the
action research plan provided in Section 5.3 which consists of seven stages:
initial meeting, diagnosis, action planning, action taking, evaluating, speci-
fying learning, and closure. The action research conducted in Organisation
B was a formal collaborative project where the Strategy Manager (the prac-
tice lead of the BPM division in Organisation B) and one of the Business
Process Analysts of the BPM division were the key stakeholders. The Strat-
egy Manager was the main industry advisor for this collaborative project.
The researcher closely followed the action research plan presented in
Section 5.3. An outline of the different stages of the action research cycle
in Organisation B is presented in the following sub-sections. Section 7.4.1
presents a summary of the initial meeting with the key stakeholders of Or-
ganisation B. An outline of the outcome of the diagnosis stage is presented
in Section 7.4.2. Section 7.4.3 presents a summary of the action planning
stage with the key stakeholders of Organisation B. A detailed outline of the
activities performed during the action taking stage is presented in Section
7.4.4. Section 7.4.5 presents the details on the evaluation stage of the ac-
tion research cycle as well as the outcome of this evaluation. An outline of
the lessons learned during this action research cycle is presented in Section
7.4.6. A briefing of the last stage of the cycle is presented in Section 7.4.7.
7.4.1 Initial Meeting
This section presents a summary of the first stage of the cycle which is the
initial meeting with the key stakeholders in Organisation B. During this
stage, the researcher organised a meeting with the Strategy Manager (the
key stakeholder in Organisation B) to discuss this collaborative opportunity
in detail. A summary of the research topic and action research approach was
sent to the invitees prior to the meeting2. During the initial meeting the re-
searcher briefly described the QoBP framework proposed by this thesis, the
2 A copy of the summary is presented in Appendix B.4.
7.4 205
action research methodology in general, and the action research protocol for
this specific collaboration. By the end of the session, the Strategy Manager
was aware of the engagement plan during the cycle and the commitment
required through the whole life cycle of the project.
Next section presents a brief summary of the next stage of the action
research cycle - diagnosis.
7.4.2 Diagnosis
The purpose of this phase was to identify a business process that will ben-
efit from the QoBP framework. During this stage, as guided by the action
research protocol presented in Section 5.3.2, the researcher conducted two
informal meetings with the Strategy Manager (the key stakeholder within
the host organisation). During these meetings the researcher described the
purpose of the diagnosis phase of the action research cycle. In order to iden-
tify a candidate process, the researcher described how the host organisation
will benefit from introducing the QoBP framework to their BPM practice.
The Strategy Manager proposed a process that was under review and
could be of benefit to this action research. The project was initiated as part
of a business process improvement initiative to improve the change manage-
ment process (referred to as dynamic development). Organisation B has an
Operations division that provides the organisation with the support of ma-
jor IT infrastructure and in-house applications development. The need for a
new application or enhancements to the existing applications, referred to as
requests for change (RFC), is usually recognised and formulated within the
business divisions across Organisation B. Lack of a proper process definition
for managing these requests for change had caused major dilemmas across
the business units. Inaccurate and inconsistent prioritisation of the RFCs
across the organisation was one of the main issues contributing to these
dilemmas. The aim of the recently initiated business process improvement
project was to be able to prioritise the requests for change across operations
based on their returned business value. A consistent scoring mechanism was
going to be introduced which was based on two values: risk & opportunity
206 7
assessment and estimated cost of the request for change being scored. The
scope of this specific project was limited to the first two phases of the BPM
life cycle, analysis and design3 for the dynamic development process. Ac-
cordingly, an in-depth understanding of the detailed process requirements
was needed during the analysis stage, followed by engineering the overall
process structure (identification and modelling of the functions, inputs &
outputs, human and non-human resources of the process) based on the re-
quirements from the analysis phase. The expected deliverable of this project
was a business process model for the dynamic development process.
From the initial descriptions that were received, this project was a suit-
able case for the second cycle of the action research. The complexity and
size of the process, in terms of functions, inputs-outputs, and resources,
was promising a substantial amount of data collection which was necessary
for the proper evaluation of the QoBP framework, specifically the quality
dimensions of the process and the practicality of the supporting methodol-
ogy. The nature of the process was different to the process from the first
cycle (the claim intake process) and was promising to provide a substan-
tially different set of data for the evaluation. The Strategy Manager of this
specific project was also very keen to improve the quality of the dynamic
development process.
The following section presents the next stage of the action research cy-
cle which is concerned with the planning of activities required to create a
quality-aware dynamic development process.
7.4.3 Action Planning
The purpose of this phase was to define the activities required to create
a quality-aware dynamic development process using the QoBP framework.
The researcher conducted an informal meeting with the Strategy Manager
and the Business Process Analysts to describe the QoBP methodology (pre-
sented in Section 4.4.6) and the activity plan that was based on the procedu-
ral steps of this methodology. Figure 7.1 presents an outline of the activity
3 Refer to Section 2.2.3 for detailed description on analysis and design phases of the BPM lifecycle.
7.4 207
plan scheduled for the next stage of the action research cycle - action taking. Ph ase Sub-A ctivity Engagem ent Type D uration A ction Research Cycle – A ction Taking A nalyse the Process W orkshop 4 hou rs Create Business Process M odel W orkshop 16 ho urs Create Q uality M o del W orkshop 16 ho urs Create Softgoal M o del W orkshop 16 ho urs Create Correlatio ns M o del N one 4 hou rs Create M easurem ent M o del W orkshop 8 hou rs Prepare Pro ject Rep ort N one 40 ho urs
Fig. 7.1. Plan for the Action Taking Phase
An outline of the next stage of the action research cycle in Organisation
B is presented below.
7.4.4 Action Taking
The purpose of this stage was to perform the activities identified during
the action planning stage. The researcher organised a series of workshops
with the Strategy Manager and the Business Process Analysts according to
the action plan produced during the action planning stage (figure 6.1). The
researcher followed the action research protocol, presented in the previous
chapter (Chapter 5), for each workshop during this stage. The QoBP au-
tomation tool developed as a result of the first action research cycle was
208 7
used to automate some of the more onerous steps of the QoBP methodol-
ogy4.
An outline of the activities performed during this stage is presented in
this section in the following order. Section 7.4.4.1 presents an outline of the
first step in which the requirements for the dynamic development process
were analysed. Section 7.4.4.2 presents the dynamic development business
process model created during the second step. The quality model created
for the dynamic development process during the third step is presented in
Section 7.4.4.3. Section 7.4.4.4 presents the softgoal model for the dynamic
development process which was created during the fourth step. The corre-
lation model for the dynamic development process created during the fifth
step is presented in Section 7.4.4.5. Finally, Section 7.4.4.6 presents the
measurement model for the dynamic development process created in the
last step of the action taking phase.
7.4.4.1 Step 1 - Analyse the Business Process
The purpose of the first step was to analyse the dynamic development pro-
cess goals, the dynamic development process environment, the organisa-
tion structure, and the dynamic development process quality requirements.
For this step, the researcher organised a workshop with the Strategy Man-
ager and the Business Process Analysts and followed the procedures and
guidelines provided by the action research protocol presented in Chapter 5.
During the workshop, the functional and quality (non-functional) require-
ments of the dynamic development process were elicited, taking account of
the organisation’s strategy, goals and structure. The researcher used the
techniques and guidelines provided in Section 5.3.4.1.1 to elicit these re-
quirements. The deliverable of this phase was the functional and quality
(non-functional) requirements description of the dynamic development pro-
cess. A brief overview of this description is presented below, followed by a
summary of the quality requirements for the dynamic development process.
4 Refer to Section 6.5.2 for further details on this tool.
7.4 209
7.4.4.1.1 Overview of the Dynamic Development Process
In summary, the dynamic development process is the process of managing
a system change request from the time it has been requested to when it
is delivered. A request for change (referred to as RFC ) is usually initiated
from a business division within the organisation. An Operation Relation
Manager (ORM) receives the RFC and lodges the RFC into the ITSM sys-
tem. ITSM is a system that is used to maintain the requests for change. All
the requests for change must be prioritised across operations based on their
business value using a consistent scoring mechanism. The scoring mecha-
nism is based on two values: risk & opportunity assessment and estimated
cost of the request for change being scored. A Change Manager is responsi-
ble for providing a costing estimate for the newly created RFC which will be
reviewed and ranked by a review committee (SMILE Review Committee).
The SMILE Review Committee is responsible for communicating the list of
the requests for change (which is ordered based on their priority number)
to the relevant business parties. The RFC will eventually be developed by
IT Development Team based on its position in the ranking list. After be-
ing developed, the requested change will be tested and released. After the
change is released, a survey will be conducted to ensure the staff within the
business division who requested the change are satisfied with the delivered
change.
It was important for Organisation B to provide a change management
process that improves the existing services. The summary of the quality
requirements elicited during this stage are as follows:
• Timely and accurate adminstration of the newly received RFC,
• Understanding the needs of the business unit requesting the change,
• Accurate estimation of the costs associated with the new RFC,
• Accurate and consistent prioritisation of the RFC across operation, and
• Value the business unit requesting the change;
210 7
Having gathered and documented the functional and quality require-
ments of the dynamic development process, the next step was to start the
design phase and model the dynamic development process using the business
process modelling notation used by Organisation B. This step is presented
in the following section.
7.4.4.2 Step 2 - Create Business Process Model
The purpose of this step was to model the dynamic development process us-
ing a business process modelling language5. As described in Section 5.3.4.1.2,
the researcher conducted two workshops with the Strategy Manager and the
Business Process Analysts to model the overall structure of the dynamic de-
velopment process based on the functional requirements defined in the pre-
vious step. During the workshops, the researcher followed the methodology
and guidelines provided by the action research protocol (Section 5.3.4.1.2)
to identify: (1) activities of the dynamic development process, (2) specifica-
tion of human resources involved with activities and their role within the
organisation, (3) specification of non-human resources (such as computer
systems, printers, projectors etc) required for activities, and (4) the specifi-
cation of data & information associated with the activities. The deliverable
of this step was an EPC model for the dynamic development process which
is presented in Figure 7.26. EPC was chosen because it was the preferred
business process notation by the participating organisation.
In summary, the dynamic development process consists of 9 functions:
enter the request details into ITSM , calculate costs, review & rank the case
- SMILE Review Forum, enter SMILE ranking into ITSM, communicate to
Staff and clients, develop the change, conduct UAT, release, and conduct cus-
tomer satisfaction survey. The dynamic development process starts when an
Operation Relation Manager (ORM) receives a Request for change (RFC).
The RFC is entered into the ITSM system (a system that is used to main-
tain the RFC details - enter the request details into ITSM ). The Change
5 Refer to the QoBP methodology presented in Section 4.4.6 for further details on this step.6 The researcher was playing a more passive role during these workshops and her role was just toensure that four dimensions of the dynamic development process (functions, inputs & outputs,human resources and non-human resources) were modelled. The Business Process Managerwas more actively involved in the modelling exercise using their established framework (asmentioned in Section 4.4.6.2, the QoBP framework proposed in this research is not bound toany specific business process modelling methodology or notation).
7.4 211
Request is received
Enter request details into
ITSM
Request details entered
Review & rank the case -SMILE Review Forum
Case reviewed &
ranked
Enter SMILE ranking into
ITSM
SMILE ranking entered
Communicate to staff and clients
Conduct UAT
Calculate costs
Develop the change
Communicated to staff and
clients
Costs calculated
Conduct customer
satisfaction survey
Release
The change developed
UAT conducted
The change released
Survey conducted
Release Manager
Business Team
SMILE Review Committee
Change Manager
Operation Relationship
Manager
Operation Relationship
Manager
IT Team
Operation Relationship
Manager
Change Request
Risk & Opportunity Assessment
RFC v1
RFC v1
RFC v2Business
Value Score
RFC v2Business
Value Score
Priority List
Priority List
Priority List
RFC v2
Priority List
Change
Change
Signed off Change
Signed off Change
Signed off Change
Survey Results
Quesntionaire
Change Manager
Fig. 7.2. Dynamic Development Process EPC
212 7
Manager then calculates the costs for the new RFC (calculate costs). The
RFC and its estimated costs are reviewed and ranked by the SMILE review
committee (review & rank the case - SMILE Review Forum). The rank-
ing list is communicated to the relevant parties by the Operation Relation
Manager (communicate to Staff and clients). The change being requested
is then developed by the IT Development Team (develop the change). Upon
the completion of the development, UAT7 is conducted by the business di-
vision (users who requested the change) (conduct UAT ). Upon successful
UAT the change being developed is released to be used by the business di-
vision who requested the change (release). The last function of the process
is performed after the change is released to ensure the staff within the busi-
ness division who requested the change are satisfied with the change being
delivered (conduct customer satisfaction survey).
Having modelled the dynamic development process, the next step was to
define a quality model for the process which is presented in the following
section.
7.4.4.3 Step 3 - Create a Quality Model
The purpose of this step was to create a quality model for the dynamic de-
velopment process8. During this step, the researcher conducted four work-
shops with the Strategy Manager and the Business Process Analysts to
capture the quality characteristics for the four business process quality di-
mensions (functions, inputs-outputs, human resources, and non-human re-
sources). During the workshops, the researcher followed the methodology
and guidelines provided by the action research protocol, presented in Sec-
tion 5.3.4.1.3, and used the QoBP automation tool to automate the creation
of the quality model for input & output and non-human resource dimen-
sions9. The outcome of these workshops was a quality model consisting of
the quality characteristics for the four dimensions of the dynamic devel-
opment process. The four quality dimensions of the dynamic development
7 User Acceptance Testing (UAT) is an important stage of a software development life cycle inwhich users who requested the change evaluate the system/functionality being developed toaccept the system/functionality.
8 Refer to the QoBP methodology presented in Section 4.4.6 for further details on this step.9 As described in Section 6.5.2, the QoBP automation tool was developed as a result of the firstaction research cycle to automate some of the more onerous steps of the QoBP methodology.
7.4 213
process are presented below.
Function Quality Dimension
The purpose the first workshop was to identify the quality characteristics
of the function dimension of the dynamic development process. It was cru-
cial to ensure that the quality characteristics selected were aligned with
the quality requirements defined during the first step (see Section 7.4.4.1).
Therefore, the first exercise was to map the high level quality requirements
defined during the first step to the functions of the dynamic development
process. As listed below, this mapping did associate each defined quality
requirement to one or more functions of the dynamic development process:
• Requirement 1 - Timely and accurate adminstration of the newly received
RFC
– Function - Enter the request details into ITSM
– Function - Calculate costs
– Function - Review & rank the case - SMILE Review Forum
– Function - Enter SMILE ranking into ITSM
– Function - Communicate to staff and clients
• Requirement 2 - Understanding the needs of the business unit requesting
the change
– Function - Review & rank the case - SMILE Review Forum
– Function - Communicate to staff and clients
– Function - Develop the change
– Function - Conduct UA
• Requirement 3 - Accurate estimation of the costs associated with the
new RFC
– Function - Calculate costs
• Requirement 4 - Accurate and consistent prioritisation of the RFC across
operation
– Function - Review & rank the case - SMILE Review Forum
214 7
• Requirement 5 - Value the business unit requesting the change
– Function - Review & rank the case - SMILE Review Forum
– Function - Communicate to staff and clients
The next exercise was to capture and model the function quality dimen-
sion of the dynamic development process. Three templates provided by the
action research protocol (Section 5.3.4.1.3) were used during this workshop
to capture and model the function quality dimension of the dynamic devel-
opment process.
Suitability Accuracy Security Reliability Understandability Learnability Time behavio
ur efficiency Resource utilisation Effectiveness Productivity Safety Satisfaction Robustness Total
Enter request details into ITSM Y Y Y Y Y Y Y Y Y 9Calculate Costs Y Y Y Y Y Y Y Y 8Review & rank the case - SMILE Review Forum Y Y Y Y Y Y Y Y Y Y Y 11Enter SMILE ranking into ITMS Y Y Y Y Y 5Communicate to staff and clients Y Y Y Y Y Y Y Y Y 9Develop the change Y Y Y Y Y Y Y Y Y y 10Conduct UAT Y Y Y Y Y Y Y Y Y Y Y 11Release Y Y Y Y Y Y Y Y Y Y 10Conduct customer satisfaction survey Y Y Y Y Y Y Y Y 8Total 6 9 3 9 8 7 8 6 9 4 0 7 5Fig. 7.3. Dynamic Development Process - Function Quality Dimension (captured as yes or no)
The first matrix, applying the boolean value, is presented in Figure 7.3.
The workshop participants rated the function/quality characteristic combi-
nation by determining whether the combination was important or not. This
enabled the calculation of both a function total and a quality characteristic
total (yes count) which provides a quick way to identify 1) the functions
that play an important role in the quality of the process, and 2) the quality
characteristics that are important for the process.
In this instance, the functions: review & rank the case - SMILE review
forum (11), conduct UAT (11), develop the change (10), and release (10)
scored the highest ratings therefore play a more significant role in the quality
outcomes for the incident management process. This exercise also identified
7.4 215
024681012
Fig. 7.4. Dynamic Development Process - Functions Quality Rating
that the functions enter SMILE ranking into ITSM (5) play a less important
role in the quality outcomes for the dynamic development process. These
results are displayed graphically in Figure 7.4.
0123456789
Fig. 7.5. Dynamic Development Process - Quality Characteristics
The quality characteristics: accuracy (9), reliability (9) and effectiveness
(9) scored the highest ratings therefore highlighting these characteristics as
more important for this process. This exercise also identified that safety (0)
216 7
and security (3) are less important characteristics for this process. These
results are displayed graphically in Figure 7.5.
Suitability Accuracy Security Reliability Understandability Learnability Time behavio
ur efficiency Resource utilisation Effectiveness Productivity Safety Satisfaction Robustness Total
Enter request details into ITSM 3 3 3 3 1 13Calculate Costs 2 2 2 2 2 1 11Review & rank the case - SMILE Review Forum 2 2 3 2 3 12Enter SMILE ranking into ITMS 0Communicate to staff and clients 1 1 1 3 6Develop the change 3 1 3 3 3 2 3 1 19Conduct UAT 2 1 2 5Release 1 1 2 4Conduct customer satisfaction survey 1 1 2Fig. 7.6. Function Quality Dimension (by functions - columns)
The next matrix, in which participants determined the top 3 functions for
each quality characteristics, is presented in Figure 7.6. The totals obtained
for each function by this approach highlight that the functions: develop the
change (19), enter request details into ITSM (13), and review & rank the
case - SMILE review forum (12) are the more important functions for ob-
taining quality outcomes. The functions: Enter SMILE ranking into ITSM
(0), and conduct customer satisfaction survey (2) play a less important role
in the quality outcomes for the dynamic development process. These results
are displayed graphically in Figure 7.7.
The next matrix, in which participants determined the top 3 quality
characteristics for each function, is presented in Figure 7.8.
The totals obtained for each quality characteristic by this approach high-
light that the quality characteristics: accuracy (13), satisfaction (11), and
effectiveness (10) are the significant quality characteristics for the dynamic
development process. Also the quality characteristics: security (0), learn-
ability (0), and safety (0) play a less important role in the quality outcomes
for the dynamic development process. These results are displayed graphi-
7.4 217
02468101214
Fig. 7.7. Claim Intake Process - Quality Rating by Functions
Suitability Accuracy Security Reliability Understandability Learnability Time behavio
ur efficiency Resource utilisation Effectiveness Productivity Safety Satisfaction Robustness
Enter request details into ITSM 3 1 2Calculate Costs 3 1 2Review & rank the case - SMILE Review Forum 2 3 1Enter SMILE ranking into ITMS 3 2 1Communicate to staff and clients 1 2 3Develop the change 3 1 2Conduct UAT 3 1 2Release 1 2 3Conduct customer satisfaction survey 1 3 2Total 3 13 0 9 2 0 3 0 10 2 0 11 1
Fig. 7.8. Function Quality Dimension (by rows - quality characteristics)
cally in Figure 7.9.
The following sub-section presents the outcome of the second workshop
conducted to model the input & output quality dimension of the dynamic
development process.
Input & Output Quality Dimension
The purpose of the second workshop was to create the quality characteris-
tics of the input & output dimension of the dynamic development process.
During the workshop, the researcher created a quality model for the input
218 7
02468101214
Fig. 7.9. Dynamic Development Process - Quality Rating
& output dimension of the dynamic development process using the QoBP
automation tool10 which is presented in Figure 7.10.
Each row of this table (Figure 7.10) represents an input or output for
a function of the dynamic development process and the columns represent
the quality characteristics of the input & output dimension. The cells of the
matrix therefore represent an input-output/quality characteristic relevancy
where a ‘Y’ is present indicates the existence of a relevancy. The automat-
ically generated input & output quality characteristics were reviewed by
the workshop participants and the non-relevant quality characteristics were
marked as ‘N’. The outcome of the second workshop was an input & output-
quality matrix presented in Figure 7.11.
The following sub-section presents the outcome of the third workshop
conducted to model the human resource quality dimension of the dynamic
development process.
Human Resources Quality Dimension
The purpose of the third workshop was to identify the quality characteris-
tics of the human resource dimension of the dynamic development process.
The template and rating approach provided by the action research proto-
10 Refer to Appendix C.11 for further details on how to use the tool to create the input & outputquality model.
7.4 219
Function Inputs Outputs
Accu
racy
Objec
tivity
Belie
vabil
ity
Repu
tation
Acce
ssibil
ity
Secu
rity
Relev
ancy
Value
-adde
d
Timeli
ness
Comp
leten
ess
Amou
nt of
data
Unde
rstan
bility
Conc
ise Re
pres
entat
ion
Cons
isten
t Rep
resen
tation
F1 - Enter request details into ITSM Change Request Y Y Y Y Y Y Y Y Y YRisk and Opportunity Assessment Y Y Y Y Y Y Y Y Y YRFC v1 Y Y Y Y Y Y Y Y Y YF2 - Calculate Costs RFC v1 Y Y Y Y Y Y Y YRFC v2 Y Y Y Y Y Y Y YBusiness Value Score Y Y Y Y Y Y Y YF3 - Review and rank the case - SMILE review form RFC v2 Y Y Y Y YBusiness Value Score Y Y Y Y YPriority List Y Y Y Y YF4 - Enter SMILE ranking into ITSM Priority List Priority List Y Y Y Y Y Y Y Y YF5 - Communicate to staff and clients Priority List Y Y Y Y YF6 - Develop the change RFC v2 Y Y Y Y Y Y Y Y Y YChange Y Y Y Y Y Y Y Y Y YF7 - Conduct UAT Change Y Y Y Y Y Y Y Y YSigned off change Y Y Y Y Y Y Y Y YF8 – Release Signed off change Y Y Y Y Y Y Y YF9 - Conduct customer Questionnaire Y Y Y Y Y Y Y Y YSurvey Result Y Y Y Y Y Y Y Y Y
Fig. 7.10. Dynamic Development Process - Input & Output Quality Dimension (Before Vali-dation)
col (Section 5.3.4.1.3) was used during this workshop to capture and model
the human resource quality dimension of the dynamic development process.
During the workshop, the participants were asked to select a boolean value
(Yes or No) in each cell of the matrix to specify whether a quality charac-
teristic is important for the human resource allocated to a function.
The outcome of the third workshop was the table presented in Fig-
ure 7.12. Each row of this table represents a function of the dynamic devel-
opment process and the columns represent quality characteristics of human
resource dimension. Where a quality characteristic is relevant to the func-
tion then a Y (for yes) is present in the appropriate cell. The totals in a
row represents the number of quality characteristics relevant to the function
220 7
Function Inputs Outputs
Accu
racy
Objec
tivity
Belie
vabil
ity
Repu
tation
Acce
ssibil
ity
Secu
rity
Relev
ancy
Value
-adde
dTim
eline
ssCo
mplet
enes
sAm
ount
of da
ta
Unde
rstan
bility
Conc
ise Re
pres
entat
ion
Cons
isten
t Rep
resen
tation
F1 - Enter request details into ITSM Change Request Y Y Y Y N Y Y Y Y YRisk and Opportunity Assessment Y Y Y Y N Y Y Y Y YRFC v1 Y N N N Y N Y N Y YF2 - Calculate Costs RFC v1 Y N N N Y Y N NRFC v2 Y N N N Y Y N NBusiness Value Score Y Y Y Y Y Y N NF3 - Review and rank the case - SMILE review form RFC v2 Y Y Y Y YBusiness Value Score Y Y Y Y YPriority List Y Y Y Y YF4 - Enter SMILE ranking into ITSM Priority List Priority List Y Y Y Y Y Y Y Y YF5 - Communicate to staff and clients Priority List Y Y Y Y YF6 - Develop the change RFC v2 Y N N N Y Y Y Y Y YChange Y Y Y Y Y Y Y Y Y YF7 - Conduct UAT Change Y Y Y Y Y Y Y Y YSigned off change Y Y Y Y Y N N Y NF8 – Release Signed off change Y N N N Y N N N NF9 - Conduct customer Questionnaire N N N N N N N N NSurvey Result Y Y Y Y Y Y Y Y NFig. 7.11. Dynamic Development Process - Input & Output Quality Dimension (After Valida-tion)
in that row. For example, totals of 3 for the function calculate costs indi-
cates that 3 quality characteristics out of 6 are relevant and important to
this function. By viewing this table it was easy for the key stakeholders to
identify the functions where human resources play an important role in the
quality of the process. The column totals are indicators on the relevancy of
each quality characteristic in the whole process. For example, experience,
and time management have the highest totals (8) which indicates that these
quality characteristics are very important for the process. On contrary, cer-
tification and leadership which have the lowest total (0) indicates that they
are not of significant importance to this process.
In this instance, the resource responsible for the functions: develop the
change (5), and release (5) scored the highest ratings therefore play a more
significant role in the quality outcomes for the dynamic development pro-
cess. This exercise also identified that the resources responsible for the func-
7.4 221
Doma
in Kn
owled
ge
Quali
ficati
on
Certi
ficati
on
Expe
rienc
e
Time M
anag
emen
t
Comm
unica
tion S
kill
Lead
ership Total
Enter request details into ITSM Y Y 2Calculate Costs Y Y y 3Review & rank the case - SMILE Review Forum Y Y Y Y 4Enter SMILE ranking into ITMS Y 1Communicate to staff and clients Y Y Y 3Develop the change Y Y Y Y Y 5Conduct UAT Y Y Y Y 4Release Y Y Y Y Y 5Conduct customer satisfaction survey Y Y 2000Total 5 2 0 8 8 6 0
Fig. 7.12. Dynamic Development Process - Human Resource Quality Dimension
00.511.522.533.544.55
Fig. 7.13. Dynamic Development Process - Human Resource Quality Rating
tions enter SMILE ranking into ITSM (0) plays a less important role in the
quality outcomes for the dynamic development process. These results are
displayed graphically in Figure 7.13.
222 7
012345678
Fig. 7.14. Dynamic Development Process - Quality Characteristics
The quality characteristics: experience (8), and time management (8)
scored the highest ratings therefore highlighting these characteristics as
more important for this process. This exercise also identified that certi-
fication (0), and leadership (0) are less important characteristics for this
process. These results are displayed graphically in Figure 7.14.
The following sub-section presents the outcome of the fourth workshop
conducted to model the non-human resource quality dimension of the dy-
namic development process.
Non-Human Resources Quality Dimension
The purpose of the fourth workshop was to identify the quality charac-
teristics of the non-human resource dimension of the dynamic development
process. During the workshop, the researcher created a quality model for the
non-human resource dimension of the dynamic development process using
the QoBP automation tool11 which was reviewed by the workshop partici-
pants.
The outcome of this workshop was an automatically generated non-
human resource quality model for the dynamic development process which
11 Refer to Appendix C.11 for further details on how to use the tool to create the input & outputquality model.
7.4 223
Suita
bility
Accu
racy
Secu
rity
Relia
bility
Unde
rstan
dabil
ity
Learn
abilit
y
Time b
ehav
iour e
fficien
cy
Reso
urce u
tilisat
ion
Effec
tiven
ess
Produ
ctivit
y
Safet
y
Satis
factio
n
Robu
stnes
s
Enter request details into ITSM ITSM System 3 1 2Calculate Costs ITSM System 3 1 2Review & rank the case - SMILE Review Forum ITSM System 2 3 1Enter SMILE ranking into ITMS ITSM System 3 2 1
Total 0 9 0 3 2 0 1 0 5 0 0 3 1
Fig. 7.15. Dynamic Development Process - Non Human Resource Quality Dimension (by rows- quality characteristics)
is presented in Figure 7.15.
0123456789
Fig. 7.16. Dynamic Development Process - Non Human Resource Quality Rating
The totals obtained for each quality characteristic by this approach high-
lights that the quality characteristic accuracy (9) is the most significant
quality characteristics for the dynamic development process. Also the qual-
ity characteristics: security (0), learnability (0), resource utilisation (0) and
safety (0) play a less important role in the quality outcomes for the dynamic
development process. These results are displayed graphically in Figure 7.16.
224 7
The next step after creating the quality model for the dynamic develop-
ment process is to create a softgoal model which is presented below.
7.4.4.4 Step 4 - Create Softgoal Model
The purpose of this step was to create a softgoal model for the dynamic de-
velopment process12. During this step, the researcher conducted four work-
shops with the key stakeholders to capture softgoals for the quality charac-
teristics identified for the four dimensions (functions, inputs-outputs, human
resources, and non-human resources) of the dynamic development process.
During the workshops, the researcher followed the methodology and guide-
lines provided by the action research protocol presented in Chapter 5.3.4.1.4.
The outcome of the first workshop was a softgoal model for the function
quality dimension which is presented in Appendix D.1. The softgoal model
for the input & output quality dimension that was created during the second
workshop is presented in Appendix D.2. The softgoal model for the human
resource quality dimension that was created during the third workshop is
presented in Appendix D.3. Finally, the outcome of the fourth workshop
was a softgoal model for the non-human resource quality dimension which
is presented in Appendix D.4.
The following section outlines the next activity conducted during the
action taking stage of the of the action research cycle in Organisation B.
7.4.4.5 Step 5 - Create Softgoal Correlations Model
The purpose of this step was to create a correlation model for the dynamic
development process13. During this step, the researcher followed the method-
ology, guidelines and algorithm provided by the action research protocol pre-
sented in Section 5.3.4.1.5 to create correlations between softgoals defined in
the previous step. The outcome of this step was a softgoal correlation model
12 Refer to Sections 4.4.2 and 4.4.6.4 for further details on the softgoal model.13 Refer to Sections 4.4.3 and 4.4.6.5 for further details on the softgoal correlation model.
7.4 225
for the dynamic development process which is presented in Appendix D.5.
The following section outlines the last activity conducted during the of
the action taking stage of the action research cycle in Organisation B.
7.4.4.6 Step 6 - Create Measurement Model
The purpose of this step was to create a measurement model for the dynamic
development process14. The measurement model contains the measurable
attributes (referred to quality metrics) that are identified to evaluate the
quality characteristics of the business process that are modelled in the form
of softgoals. As described in Section 4.4.4, this research adopts an approach
similar to the GQM [147] approach in refining softgoals to a set of quality
metrics. Each softgoal is refined into a set of questions and then each ques-
tion is refined into a set of quality metrics.
During this step, the researcher conducted four workshops with the Strat-
egy Manager and the Business Process Analysts to create a measurement
model which contains quality metrics required to measure softgoal satisfac-
tion for the softgoal model created for the dynamic development process.
During the workshops, the researcher followed the methodology and guide-
lines provided by the action research protocol presented in Chapter 5.3.4.1.6.
The outcome of the first workshop was a measurement model for the
function quality dimension which is presented in Appendix D.6. The mea-
surement model for the input & output quality dimension that was created
during the second workshop is presented in Appendix D.7. The measure-
ment model for the human resource quality dimension that was created
during the third workshop is presented in Appendix D.8. Finally, the out-
come of the fourth workshop was a measurement model for the non-human
resource quality dimension which is presented in Appendix D.9.
The following section outlines the next step of the action research cycle
in which the outcome of the activities performed during the action taking
14 Refer to Sections 4.4.4, and 4.4.6.6 for further details on the measurement model.
226 7
stage was evaluated.
7.4.5 Evaluation
The main purpose of this stage was to evaluate the applicability, usability,
usefulness, and scalability of the QoBP framework used during the action
taking stage to create a quality-aware dynamic development process. As
outlined at the beginning of this chapter, this action research cycle was
conducted according to the guidelines provided by the action research pro-
tocol that was presented in Chapter 5. To ensure the rigor of the evaluation
phase of this study15, a set of evaluation objectives have been developed
and presented in Section 5.3.5. The action research protocol also provided
a questionnaire that was created based on these evaluation objectives16.
During this step, the researcher conducted two workshops to evaluate
the outcome of the action research with the the Strategy Manager and the
Business Process Analysts. The main purpose of the evaluation stage of the
action research cycle was explained to the key stakeholders at the begin-
ning of the workshop series. The questionnaire provided by the action re-
search protocol was used to guide the discussions during the workshops. The
researcher followed the three communication behaviours recommended by
[184] to ensure that each evaluation objective was communicated effectively.
The outcome of the evaluation workshop, with respect to the evaluation ob-
jectives, include:
• Quality model:
– Applicability of the quality characteristics defined for the four quality
dimensions (function quality dimension, input & output quality di-
mension, human resource quality dimension, and non-human resource
quality dimension) of the quality model was confirmed. The objectives
here was to validate that the quality characteristics for the four dimen-
sions are relevant and applicable to business processes. While these
15 Refer to guideline 5 - research rigor [2] described in Section 3.6 of chapter3.16 This questionnaire is provided in Appendix B.5.
7.4 227
quality characteristics17 were defined based on an extensive literature
review in related areas18, and their applicability was confirmed once
during the first action research cycle, it was crucial to evaluate their
applicability during the second action research cycle. The relevancy
and the appropriateness of each quality characteristic with respect to
its quality dimension was reviewed during the evaluation workshops
and was acknowledged by the workshops participants. Comments from
the workshop participants include: “ ... not all the provided quality
characteristics were relevant and appropriate for the dynamic develop-
ment process, but that does not mean that they would not be relevant
for other processes ... ”.
– Usability and scalability of the QoBP methodology, QoBP automation
tool19 and the supporting templates (provided in Section 5.3.4.1.3) to
identify and capture the quality characteristics for the four quality di-
mensions of the selected business process was confirmed. The usability
and scalability limitations of the QoBP methodology to capture the
quality characteristics for input & output dimension that was iden-
tified during the first cycle of the action research20, was rectified by
introducing the QoBP automation tool. Comments from the workshop
participants include: “...the templates were really good in helping us
to select the appropriate quality characteristics...it was very useful to
see different views, for example the functions that contribute the most
to the quality of the whole process or which quality characteristic is
the most relevant to the whole process...”.
• Softgoal model:
– Applicability of the softgoal model of the QoBP framework was con-
firmed by the workshop participants. It was acknowledged that the
17 Refer to Section 4.3 for further details on four quality dimensions of a business process.18 Refer to Section 4.3.1 for a summary of this literature review.19 The QoBP automation tool was developed after conducting the first action research cycle to
improve the scalability of the QoBP methodology by automating some of the more oneroussteps of the QoBP methodology. QoBP automation tool is described in details in AppendixC.11.
20 Refer to Section 6.4.5 for further details on the evaluation results of the first action researchresults.
228 7
goal-oriented approach adopted in this research is a relevant and ap-
propriate approach in coping with the abstract and informal nature
of non-functional requirements in the form of quality characteristics.
Comments from the workshop participants confirming the applica-
bility of the softgoal model include: “...the quality characteristics, on
their own, were difficult to apply...the softgoals made it easier to relate
them to the process...”.
– Practicality of the QoBP methodology and the supporting templates
(provided in Section 5.3.4.1.4) to identify and capture softgoals for the
identified quality characteristics for the dynamic development process
was confirmed. After reviewing the softgoal model of the dynamic de-
velopment process, it became apparent that because all the softgoals
are specified using the same pattern21, a set of generic softgoals can
be developed for all the quality characteristics that can be used as
starting point in future cases. Comments from the workshop partici-
pants reflects this: “...given that the softgoals follow a similar format,
we think that they could be pre-defined as this would save us consid-
erable effort...”.
• Softgoal correlation model:
– Practicality and scalability of the QoBP methodology and the sup-
porting templates (provided in Section 5.3.4.1.5) to capture the cor-
relations between identified softgoals was reviewed during the evalu-
ation workshops. It was acknowledged that “...the methodology and
the supporting template may not scale well for larger business pro-
cesses...”. It was discussed that as the correlations are modelled based
on a specific algorithm22, a tool could be developed to automate the
creation of the softgoal correlation model for a business process.
• Measurement model:
– Practicality and scalability of the QoBP methodology and the sup-
porting templates (provided in Section 5.3.4.1.6) to create a measure-
21 Refer to Section 4.4.2 for further details on the recommended pattern to specify softgoals.22 Refer to Section ?? for further details on how to create a softgoal correlation model.
7.4 229
ment model was confirmed. It was also acknowledged that the goal-
question-metric approach was very effective in refining each softgoal
to a set of quality metrics as it was providing a structured approach
that, while being efficient, was easy to follow. Comments from the
workshop participants include: “...the definition of metrics that could
be derived from the quality goals in an easy, systematic way was very
useful...”.
• QoBP Metamodel:
– Validity of the QoBP metamodel proposed in Section 4.4.5.2 in pro-
ducing a quality-aware business process was confirmed. This objective
was met, as it was acknowledged that the QoBP metamodel captures
the necessary entities to produce a quality-aware business process.
Comments from the workshop participants include: “...the model cap-
tured the necessary elements to define the quality aspects of the busi-
ness process...”.
During the last evaluation workshop it was also acknowledged by the
Strategy Manager that:
“...having a way to embed the quality elements into our business process
model was beneficial...”.
“...this process has made me to become more aware of quality and the
role it can play in business process improvement exercises...”.
The following section outlines a summary of the next step of the first
action research cycle in which the lessons learned from the action research
cycle were identified.
7.4.6 Specifying Learning
The purpose of this step was to identify the lessons learned during the
second action research cycle. During this stage, the researcher organised
230 7
a workshop with the Strategy Manager and the Business Process Analysts
to reflect on the evaluation results described in the previous section. This
workshop was focused on discovering the lessons learned and eliciting the
recommendations for possible enhancements to the QoBP framework. The
outcome of the first workshop can be summarised as:
1. A generic softgoal model can be generated and be available as part of
the framework.
2. Develop a tool that automates the generation of a softgoal model and a
softgoal correlation model.
Next section presents a summary of the final stage of the action research
cycle with Organisation B - closure.
7.4.7 Closure
During this last stage of the action research, the researcher organised an
informal meeting to express her appreciation to the Strategy Manager and
the Business Process Analysts contributing to this collaborative project.
7.5 A Reflection on Action Research Cycle and
Re-design
This section presents further reflection on the two enhancement opportuni-
ties identified during the specifying learning stage of the second action re-
search cycle (Section 7.4.6) and their realisations. The enhancements made
to the artifacts as a result are also presented in this section.
7.5.1 Create a Generic Softgoal Model
This section presents an outline of the first enhancement to the QoBP frame-
work. After completing the second cycle of the action research in Organisa-
tion B it became apparent that a generic softgoal model can be created and
7.6 231
incorporated into the QoBP framework. The generic softgoal model can be
used as a starting point during the fourth step of the QoBP methodology
(create softgoal model - see Section 4.4.6.4). These generic softgoals can
then be refined to be more specific for a business process.
7.5.2 QoBP Automation Tool
This section presents a brief description on the enhancements to the QoBP
automation tool that was developed during the first action research cycle23.
The QoBP methodology (Section 4.4.6), and the action taking stage of the
action research plan presented in Section 5.3.4 are enhanced as the result
of these enhancements to the QoBP automation tool. The enhancements to
the action taking stage of the action research plan are as follows:
• Step 4 - Create a Softgoal Model (Section 5.3.4.1.4): the tool
creates a softgoal model automatically from the created quality model.
• Step 5 - Create a Correlation Model (Section 5.3.4.1.5): the tool
automatically creates a softgoal correlation model for a process based on
the created softgoal model for that process and the correlation algorithm
defined in Section 5.3.4.1.5.
7.6 Summary of the Second Action Research Cycle
The purpose of this chapter was to describe the second cycle of the action
research conducted as part of this study. During this cycle the validity and
applicability of the quality dimensions of the QoBP framework to a real-
world business case was evaluated. The enhancements made to the QoBP
framework and the QoBP methodology as a result of the first action re-
search cycle (Section 7.4.6) were also evaluated in his action research cycle.
The evaluation of the second action research cycle was presented in Sec-
tion 7.4.5. Section 7.4.6 outlined the learning from this cycle. A reflection
23 The QoBP automation tool is described in detail in Appendix C.10.
232 7
on the lessons learned and the enhancements made to the framework as a
result were presented in Section 7.5. The enhancement made to the QoBP
framework include:
• Creating of a generic softgoal model
• Enhancements to the QoBP automation tool to automate the creation
of both softgoal model and Softgoal correlation model
These enhancements are evaluated in the subsequent action research cy-
cles (Chapter 8). The objectives of the second action research cycle were
met by enhancing the QoBP framework from the findings described above
after the completion of the second action research cycle.
8
Third Action Research Cycle
8.1 Introduction
This chapter presents a report on the third action research cycle conducted
in a medium-sized Australian organisation in the financial sector - Organi-
sation C. The purpose of this third action research cycle was to evaluate: (1)
the enhancements made to the artifacts during the second action research
cycles, and (2) the PRCA technique proposed in Section 4.5 to support the
quality improvement phase of the quality-aware BPM life cycle.
The action research conducted in Organisation C was based on the key
principles of action research as presented in Chapter 3, and the action re-
search protocol presented in Chapter 5. The data captured and the models
built during this cycle are presented either in the relevant sections of this
chapter or Appendix E. Section 8.2 presents a short description of Organisa-
tion C, followed by Section 8.3 which describes the justification for choosing
Organisation C as the host for the third cycle of the action research. A sum-
mary of the action research cycle stages in Organisation C is presented in
Section 8.4.
8.2 Description of the Organisation
Organisation C is one of the largest Australian independent stockbroking
and financial planning firms with over 345,000 clients, 700 financial advisors
and 970 staff operating from 41 offices in all states of Australia. This cor-
poration provides its clients with a variety of products and services such as
stockbroking, financial planning, corporate finance, and portfolio manage-
234 8
ment. The head office of the corporation is located in Queensland and has
several centralised divisions such as Operations, Information Technology,
and Market Research.
The BPM initiative at Organisation C is in the early stages. Although
there is no centralised division dedicated to BPM, several major business
process improvement and business process re-engineering initiatives have
been taking place within two divisions of the organisation. The Project
Management team in Organisation C is usually responsible for the manage-
ment and delivery of the business process improvement initiatives/projects.
The justification for choosing Organisation C as the host for the second
cycle of the action research is presented in the next section.
8.3 Justifications for the Choice of the Organisation
This section presents the justification for choosing Organisation C as the
host for the third cycle of the action research. As outlined in Section 5.2,
to gain maximum benefit from the action research phase, certain criteria
for the selection of an appropriate host organisation must be met. The
selection criteria that were provided in Section 5.2 were used to evaluate
if Organisation C is an appropriate organisation to host the third cycle
of the action research. After the initial contact with Organisation C and
discussing the purpose of the engagement, it was clear that Organisation
C was an appropriate candidate for hosting the third cycle of the action
research. This organisation was chosen to participate in the third cycle of
the action research for the following reasons:
• Criterion 1 - It was important for the organisation to have an ap-
preciation for BPM and commitment to BPM principles and practices.
Organisation C is a large organisation with a management team that are
committed to establish BPM principles and practices.
• Criterion 2 - It was important for the organisation to have an appreci-
ation for research in the area and preferably a prior relationship with the
BPM research center within the Queensland University of Technology.
8.4 235
The researcher was an employee of Organisation C who was very well
aware of the QUT BPM center research activities, rules and regulations.
• Criterion 3 - It was important for the organisation to have an ap-
preciation for quality aware BPM and be keen to introduce the quality
framework proposed by this thesis to their BPM practice. The researcher
was providing consultancy on a project which could benefit from the Pro-
cess Root Cause Analysis (PRCA) technique. It was important to choose
a business process with quality issues that could benefit from the root
cause analysis approach proposed by this thesis. The key stakeholders
for this specific project were interested in the research. They acknowl-
edged the limitations of an appropriate root cause analysis for business
processes. Therefore, they were very keen to participate in this action
research and take part in exploring the proposed PRCA technology.
• Criterion 4 - The researcher was an employee of Organisation C which
made accessibility to the organisation’s resources and people easier.
Next section presents a summary of the different stages of the action
research cycle in Organisation C.
8.4 Action Research Cycle
This section presents a detailed report on the action research cycle within
Organisation C. The action research cycle was conducted according to the
action research plan provided in Section 5.3. The action research conducted
in Organisation C was a formal collaborative project where the Project Man-
ager and a Help Desk Officer (one of the senior members of the IT Help
Desk in Organisation C) were the key stakeholders.
An outline of the different stages of the action research cycle in Organi-
sation C is presented in the following sub-sections. Section 8.4.1 presents a
summary of the initial meeting with the key stakeholders of Organisation
C. An outline of the outcome of the diagnosis stage is presented in Sec-
236 8
tion 8.4.2. Section 8.4.3 presents a summary of the action planning stage
with the key stakeholders of Organisation C. A detailed outline of the activ-
ities performed during the action taking stage is presented in Section 8.4.5.
Section 8.4.6 presents the details on the evaluation stage of the action re-
search cycle as well as the outcome of this evaluation. An outline of the
lessons learned during this action research cycle is presented in Section 8.4.7.
A briefing of the last stage of the cycle is presented in Section 8.4.8.
8.4.1 Initial Meeting
This section presents a short summary of the first stage of the cycle which
is the initial meeting with the Project Manager (the key stakeholder in Or-
ganisation C). During this stage, the researcher organised a meeting with
the Project Manager to discuss this collaborative opportunity in detail. A
summary of the research topic and action research approach was sent to
the invitees prior to the meeting1. During the initial meeting the researcher
briefly described the Process Root Cause Analysis (PRCA) technique, the
QoBP framework, the action research methodology in general, and the ac-
tion research protocol for this specific collaboration. By the end of the ses-
sion, the Project Manager was aware of the engagement plan during the cy-
cle and the commitment required through the whole life cycle of the project.
Next section presents a brief summary of the next stage of the action
research cycle - diagnosis.
8.4.2 Diagnosis
The purpose of this phase was to identify a business process that will ben-
efit from the PRCA technique. During this stage, as guided by the action
research protocol presented in Section 5.3.2, the researcher conducted two
informal meetings with the Project Manager. During these meetings the re-
searcher described the purpose of the diagnosis phase of the action research
cycle. In order to identify a candidate process, the researcher described how
the host organisation will benefit from introducing the QoBP framework
1 A copy of the summary is presented in Appendix B.4.
8.4 237
and PRCA technique to their BPM practice.
A project was underway to improve the help desk service provided by
the IT division within Organisation C2. The project, referred to as inci-
dent management, was part of a programme of work initiated as a result
of a major re-structuring of the IT division. The identification of incidents
and the resolution and restoration of affected services were not occurring
as quickly or efficiently as possible. The purpose of this project was to im-
prove the incident management process in Organisation C. The researcher,
being a consultant in Organisation C, was involved in the early stages of
this project and was aware of the lack of an appropriate tool or technique
for conducting the root cause analysis of cases where the incidents occurred
and reported were not managed efficiently by the IT help desk team (poor
quality incident management cases). After explaining to the key stakehold-
ers of this initiative how the quality of the service provided by IT help
desk can be improved by introducing the quality-aware BPM life cycle to
the incident management process, they agreed to adopt the quality-aware
BPM life cycle for this specific process. The Project Manager who had been
involved in other business process improvement initiatives, was very well
aware of the lack of the BPM methodology practiced by Organisation C in
supporting quality aspects of business processes. Therefore, she was keen
to adopt the QoBP framework for the incident management process and
use the PRCA techniquep to identify the root causes of a recurring incident
management case which did not have the desired outcome. The statement
below reflects the concerns raised in an email by the head of the division
affected by this recurring issue:
“ ... this month there have been two occasions when X batches have not
run correctly and timely support was not available ... it is imperative that
the processing of this batch occurs prior to the ASX market opening ...”
As stated in the above statement, the incident resolution and restoration
for this recurring incident were not occurring as quickly and as effectively
as desired. This quality issue with the incident management process was a
2 The IT division provides the organisation with support of major IT infrastructure and Aus-tralia wide user network. IT support is maintained by a Help Desk located at Head Office.
238 8
suitable case to evaluate the PRCA technique in a real world scenario.
The following section presents the next stage of the action research cy-
cle which is concerned with the planning of activities required to create a
quality-aware incident management process.
8.4.3 Action Planning
The purpose of this phase was to define the activities required to create
a quality-aware incident management process using the QoBP framework
and conduct root cause analysis using the PRCA technique. The researcher
conducted an informal meeting with the Project Manager and Help Desk
Officer to describe the QoBP methodology (presented in Section 4.4.6), the
PRCA technique and the activity plan for both quality definition and qual-
ity improvement phases of the quality-aware BPM life cycle.
Figure 8.1 presents an outline of the activities scheduled for the next
stage of the action research cycle - action taking. As shown in Figure 8.1,
the action taking stage consists of two distinct phases: phase I and phase II.
Phase I was dedicated to the quality definition phase of the quality-aware
BPM life cycle in which the QoBP framework was used to create a quality-
aware incident management process. Phase II was planned for the quality
improvement phase of the quality-aware BPM life cycle in which the PRCA
technique was used to identify the root cause of the quality issue identified
during the diagnosis phase. The following section presents the first phase of
the action taking stage.
8.4.4 Action Taking - Phase I
The purpose of this stage was to create a quality-aware incident manage-
ment process based on the QoBP methodology. The researcher organised a
series of workshops with the key stakeholders according to the action plan
produced during the action planning stage (Figure 6.1). The researcher
followed the action research protocol, presented in the previous chapter
(Chapter 5), for each workshop during this stage. The QoBP automation
tool developed as a result of the first action research cycle was also used to
8.4 239 Phase Sub-A ctivity Engagem ent Type D uration A ction Takin g Phase 1 A n alyse the Process W orksh op 4 ho urs Create Business Process M odel W orksh op 16 h ours Create Q uality M odel W orksh op 16 h ours Create Softgoal M odel W orksh op 16 h ours Create Correlatio ns M odel N one 4 ho urs Create M easurem ent M odel W orksh op 8 ho urs Prep are Pro ject Report N one 40 h ours A ction Takin g Phase 2 Co nduct PRCA W orksh op 8 ho urs
Fig. 8.1. Plan for the Action Taking Phase
automate some of the more onerous steps of the QoBP methodology.
An outline of the activities performed during this stage is presented in
this section in the following order. Section 8.4.4.1 presents an outline of the
first step in which the requirements for the incident management process
were analysed. Section 8.4.4.2 presents the incident management business
process model created during the second step. The quality model created
for the incident management process during the third step is presented in
Section 8.4.4.3. Section 8.4.4.4 presents the softgoal model for the incident
management process which was created during the fourth step. The corre-
lation model for the incident management process created during the fifth
step is presented in Section 8.4.4.5. Finally, Section 8.4.4.6 presents the
240 8
measurement model for the incident management process created in the
last step of the action taking phase.
8.4.4.1 Step 1 - Analyse the Business Process
The purpose of the first step was to analyse the incident management pro-
cess goals, the incident management process environment, the organisation
structure, and the incident management process quality requirements. For
this step, the researcher organised a workshop with the Business Process
Manager and Help Desk Officer. During the workshop, the functional and
quality (non-functional) requirements of the incident management process
were elicited, taking account of the organisation’s strategy, goals and struc-
ture. The researcher used the technique and guidelines provided in Section
5.3.4.1.1 to elicit these requirements. The deliverable of this phase was the
functional and quality (non-functional) requirements description of the inci-
dent management process. A brief overview of this description is presented
below, followed by a summary of the quality requirements for the incident
management process.
8.4.4.1.1 Overview of the Incident Management Process
The incident management process is the process of restoring normal service
operation, in the event of an incident, as quickly as possible with minimum
disruption to the business. Around 95% of incidents are dealt with by the IT
help desk within Organisation C. The incident management process starts
when incidents are detected and logged as Fault Service Requests (FSR).
Incident management assures appropriate levels of resources can be allo-
cated to fixing the problem. The FSR is opened by a Help Desk Officer who
carries out an initial review of the contents. Based on their initial assess-
ment the Help Desk Officer confirms that the call is either a service request
or an error report i.e. Fault Service Request (FSR). If the call is a Request
for Change (RFC) then the incident process is no longer relevant and the
Help Desk Officer should follow the Change Management process. Next,
the Help Desk Officer assigns the FSR a priority (High, Medium or Low)
based on their initial assessment. Prioritisation is performed based on two
dimensions: urgency and impact. Urgency refers to when an incident needs
8.4 241
to be resolved. Impact reflects the likely effect the incident on the business
services. Other factors such as availability of resources are also taken into ac-
count. If the FSR is assigned a high priority then a decision should be made
as to whether the incident management process is appropriate. Based on
their initial assessment the Help Desk Officer assigns the FSR to a category.
The category items are structured around the hardware, software, voice and
the specific asset or system e.g., PC, phone, web site, application A, etc.
Categorisation is required in order to determine which records from the
Knowledge Base3 are presented for assistance and guidance and also whom
the incident should be assigned for resolution. Within each classification
item there will also be multiple sub-items that further assist in resolution
by identifying the nature of the call e.g. new user, faulty, and error. Based
on the prioritisation and classification the Help Desk Officer then assigns
the call either to themselves or another IT Team member, herein called the
assignee. The assignee is responsible for the investigation and diagnosis.
It was important for the key stakeholders in the IT division to provide
an efficient incident management experience for their clients. A summary
of the quality requirements elicited during this stage are as follows:
• A consistent and measurable approach applied to all incidents,
• Incidents are prioritised and categorised correctly,
• Limited IT resources being used more effectively,
• Knowledge of incidents and their fixes that occur through centralised
recording, and
• Timely resolution of incidents based on their assigned priority and clas-
sification;
Having gathered and documented the functional and quality require-
ments of the incident management process, the next step was to start the
design phase and model the incident management process using the business
3 All the appropriate resolution paths are recorded in the Help Desk Knowledge Base.
242 8
process modelling notation used by Organisation C. This step is presented
in the following section.
8.4.4.2 Step 2 - Create Business Process Model
The purpose of this step was to model the incident management process us-
ing a business process modelling language4. As described in Section 5.3.4.1.2,
the researcher conducted a series of workshops with the Project Manager
and Help Desk Officer to model the overall structure of the change man-
agement process based on the functional requirements defined in the pre-
vious step. During the workshops, the researcher followed the methodology
and guidelines provided by the action research protocol, presented in Sec-
tion 5.3.4.1.2, to identify: (1) activities of the incident management process,
(2) specification of human resources involved with activities and their role
within the organisation, (3) specification of non-human resources (such as
computer systems, printers, projectors etc) required for activities, and (4)
the specification of data & information associated with the activities. The
deliverable of this step was an EPC model for the incident management
process which is presented in figure 7.2 6.25. EPC was chosen because it
was the preferred business process notation by the participating organisa-
tion.
In summary, the incident management process consists of 4 functions:
classify FSR , prioritise FSR, categorise FSR, and assign FSR. The inci-
dent management process starts when a FSR is received. The FSR is then
evaluated to confirm that the request is a genuine fault request and not a
Request For Change (RFC) (classify FSR). The Help Desk Officer assigns
the FSR a priority (High, Medium or Low) based on their initial assessment
(prioritise FSR). The Help Desk Officer in charge assigns a category (hard-
ware, software, voice and the specific asset or system e.g., PC, phone, web
site, application A, etc) to the FSR (categorise FSR). He/she then assigns
the call either to themselves or another IT Team member (assign FSR).
4 Refer to the QoBP methodology presented in Section 4.4.6 for further details on this step.5 The researcher was playing an active role during these workshops and she was working as aconsultant for this project. She ensured that four dimensions of the incident management pro-cess (functions, inputs & outputs, human resources and non-human resources) were modelled.The Project Manager was also actively involved in the modelling exercise.
8.4 243
FSRis received
Classify FSR
FSR
Categorise FSR
FSR isverified
XORFSR is
re-classified
XORFSR is
escalated
FSR is prioritised
FSR is categorised
FSR
Prioritise FSR
FSR
FSR
FSR
FSR
Assign FSR
FSR
FSREmail
receipt
Help Desk Officer
Help Desk Officer
Help Desk Officer
Help Desk Officer
Change Mgmt
Process
Problem Mgmt
Process
Fig. 8.2. Incident Management Process EPC
244 8
Having modelled the incident management process, the next step was to
define a quality model for the process which is presented in the following
section.
8.4.4.3 Step 3 - Create a Quality Model
The purpose of this step was to define a quality model for the incident
management process6. During this step, the researcher conducted four work-
shops with the key stakeholders to capture the quality characteristics for the
four business process quality dimensions (functions, inputs-outputs, human
resources, and non-human resources). During the workshops, the researcher
followed the methodology and guidelines provided by the action research
protocol, presented in Section 5.3.4.1.3, and used the the QoBP automation
tool to automate the creation of the quality models for input & output and
non-human resource dimensions7. The outcome of these workshops was a
quality model consisting of the quality characteristics for the four dimen-
sions of the incident management process. The four quality dimensions of
the incident management process are presented below.
Function Quality Dimension
The purpose of the first workshop was to identify the quality characteris-
tics of the function dimension of the incident management process. It was
crucial to ensure that the quality characteristics selected were aligned with
the quality requirements defined during the first step (see Section 8.4.4.1).
Therefore, the first exercise was to map the high level quality requirements
defined during the first step to the functions of the incident management
process. As listed below, this mapping did associate each defined quality
requirement to one or more functions of the incident management process:
• Requirement 1 - A consistent and measurable approach applied to all
incidents
– Function - Classify FSR
– Function - Prioritise FSR
– Function - Categorise FSR
6 Refer to the QoBP methodology presented in Section 4.4.6 for further details on this step.7 Section 6.5.2 discussed how the QoBP automation tool was developed as a result of the firstaction research cycle to automate some of the more onerous steps of the QoBP methodology.
8.4 245
– Function - Assign FSR
• Requirement 2 - Incidents are prioritised and categorised correctly
– Function - Prioritise FSR
– Function - Categorise FSR
• Requirement 3 - Limited IT resources being used more effectively
– Function - Prioritise FSR
– Function - Categorise FSR
– Function - Assign FSR
• Requirement 4 - Knowledge of incidents and their fixes that occur
through centralised recording
– Function - Classify FSR
– Function - Prioritise FSR
– Function - Categorise FSR
• Requirement 5 - Timely resolution of incidents based on their assigned
priority and classification
– Function - Classify FSR
– Function - Prioritise FSR
– Function - Categorise FSR
– Function - Assign FSR
The next exercise was to capture and model the function quality dimen-
sion of the incident management process. Three templates provided by the
action research protocol (Section 5.3.4.1.3) were used during this workshop
to capture and model the function quality dimension of the incident man-
agement process.
The first matrix, applying the boolean approach, is presented in Fig-
ure 8.3. Key stakeholders rated the function/quality characteristic combi-
nation by determining whether the combination was important or not (Yes
or No). This enabled the calculation of both a function total and a quality
characteristic total (Yes count) which provides a quick way to identify 1)
the functions that play an important role in the quality of the process, and
246 8
2) the quality characteristics that are important for the process.
Suita
bility
Accu
racy
Secu
rity
Relia
bility
Unde
rstan
dabil
ity
Learn
abilit
y
Time b
ehav
iour e
fficien
cy
Reso
urce u
tilisat
ion
Effec
tiven
ess
Produ
ctivit
y
Safet
y
Satis
factio
n
Robu
stnes
s
Total
Classify FSR Y Y Y Y Y Y Y Y 8Priotorise FSR Y Y Y Y Y Y Y Y 8Categorise FSR Y Y Y Y Y Y Y Y 8Assign FSR Y Y Y Y Y Y Y Y Y 9
Total 4 4 1 0 4 0 4 4 4 4 0 4 0
Fig. 8.3. Incident Management Process - Function Quality Dimension (captured as yes or no)
7.47.67.888.28.48.68.89Classify FSR Priotorise FSR Categorise FSR Assign FSR
Fig. 8.4. Incident Management Process - Functions Quality Rating
In this instance, the functions assign FSR (9) scored the highest rating
and therefore plays a more significant role in the quality outcomes for the
incident management process. This exercise also identified that the other
three functions classify FSR, prioritise FSR, and categorise FSR play a less
important role in the quality outcomes for the incident management pro-
8.4 247
cess. These results are displayed graphically in Figure 8.4.
00.511.522.533.54
Fig. 8.5. Incident Management Process - Quality Characteristics
Also, the quality characteristics: suitability (4), accuracy (4), understand-
ability (4), time behaviour efficiency (4), resource utilisation (4), effective-
ness (4), and productivity (4) scored the highest ratings therefore highlight-
ing these characteristics as more important for this process. This exercise
also identified that reliability (0), learnability (0), safety (0) and robustness
(0) are less important characteristics for this process. These results are dis-
played graphically in Figure 8.5.
Suita
bility
Accu
racy
Secu
rity
Relia
bility
Unde
rstan
dabil
ity
Learn
abilit
y
Time b
ehav
iour e
fficien
cy
Reso
urce u
tilisat
ion
Effec
tiven
ess
Produ
ctivit
y
Safet
y
Satis
factio
n
Robu
stnes
s
Total
Classify FSR 2 1 2 2 1 2 1 2 1 14Priotorise FSR 3 3 3 3 3 2 2 19Categorise FSR 2 1 2 1 1 2 2 1 1 2 1 16Assign FSR 1 3 3 1 3 3 3 3 3 23
Fig. 8.6. Function Quality Dimension (by functions - columns)
248 8
The next matrix, in which participants determined the top 3 functions for
each quality characteristics, is presented in Figure 8.6. The totals obtained
for each function by this approach highlight that the functions: assign FSR
(23), prioritise FSR (19), and categorise FSR (16) are the more important
functions for obtaining quality outcomes. Also the functions classify FSR
(14) plays a less important role in the quality outcomes for the incident
management process. These results are displayed graphically in Figure 8.7.
0510152025
Classify FSR Priotorise FSR Categorise FSR Assign FSRFig. 8.7. Incident Management Process - Quality Rating by Functions
The next matrix, in which participants determined the top 3 quality
characteristics for each function, is presented in Figure 8.8.
The totals obtained for each quality characteristic by this approach high-
light that the quality characteristics: suitability (6), accuracy (5), and ef-
fectiveness (6) are the significant quality characteristics for the incident
management process. Also the quality characteristics: security (0), learn-
ability (0), resource utilisation (0), productivity (0), safety (0), satisfaction
(0), and robustness (0) play a less important role in the quality outcomes for
the incident management process. These results are displayed graphically
in Figure 8.9.
8.4 249
Suita
bility
Accu
racy
Secu
rity
Relia
bility
Unde
rstan
dabil
ity
Learn
abilit
y
Time b
ehav
iour e
fficien
cy
Reso
urce u
tilisat
ion
Effec
tiven
ess
Produ
ctivit
y
Safet
y
Satis
factio
n
Robu
stnes
s
Classify FSR 2 3 1Priotorise FSR 2 1 3Categorise FSR 2 1 3Assign FSR 2 3 1
Total 6 5 0 3 0 0 4 0 6 0 0 0 0
Fig. 8.8. Function Quality Dimension (by rows - quality characteristics)
0123456
Fig. 8.9. Incident Management Process - Quality Rating
The following sub-section presents the outcome of the second workshop
conducted to model the input & output quality dimension of the incident
management process.
Input & Output Quality Dimension
The purpose of the second workshop was to create the quality characteris-
tics of the input & output dimension of the incident management process.
During the workshop, the researcher created a quality model for the input
& output dimension of the incident management process using the QoBP
250 8
automation tool8 which is presented in Figure 7.10.
Function Inputs OutputsAc
curac
yOb
jectiv
ityBe
lieva
bility
Repu
tation
Acce
ssibil
itySe
curit
yRe
levan
cyVa
lue-ad
ded
Timeli
ness
Comp
leten
ess
Amou
nt of
data
Unde
rstan
bility
Conc
ise Re
prese
ntatio
nCo
nsist
ent R
epres
entat
ion
F1 - Classify FSR FSR Y Y Y Y Y Y Y Y Y Y Y YFSR Y Y Y Y Y Y Y Y Y Y Y Y
F2 - Prioritise FSR Y Y Y Y Y Y Y Y Y Y Y Y YFSR Y Y Y Y Y Y Y Y Y Y Y Y Y
F3 - Categorise FSR Y Y Y Y Y Y Y Y Y Y Y Y YFSR Y Y Y Y Y Y Y Y Y Y Y Y Y
F4 - Assign FSR FSR Y Y Y Y Y Y Y Y Y Y Y YEmail Receipt Y Y Y Y Y Y Y Y Y Y Y Y
Fig. 8.10. Incident Management Process - Input & Output Quality Dimension (Before Valida-tion)
Each row of this table (Figure 8.10) represents an input or output for
a function of the incident management process and the columns represent
the quality characteristics of the input & output dimension. The cells of the
matrix therefore represent an input-output/quality characteristic relevancy
where a ‘Y’ is present indicates the existence of a relevancy. The automati-
cally generated input & output quality characteristics were reviewed by the
key stakeholders and the non-relevant quality characteristics were marked
as ‘N’. The outcome of the second workshop was an input & output-quality
matrix presented in Figure 8.11.
The following sub-section presents the outcome of the third workshop
conducted to model the human resource quality dimension of the incident
management process.
Human Resources Quality Dimension
The purpose of the third workshop was to identify the quality characteris-
tics of the human resource dimension of the incident management process.
The template and rating approach provided by the action research proto-
col (Section 5.3.4.1.3) was used during this workshop to capture and model
the human resource quality dimension of the incident management process.
8 Refer to Appendix C.11 for further details on how to use the tool to create the input & outputquality model.
8.4 251
Function Inputs Outputs
Accu
racy
Objec
tivity
Belie
vabil
ityRe
putat
ionAc
cessi
bility
Secu
rity
Relev
ancy
Value
-adde
dTim
eline
ssCo
mplet
enes
sAm
ount
of da
taUn
derst
anbil
ityCo
ncise
Repre
senta
tion
Cons
isten
t Rep
resen
tation
F1 - Classify FSR FSR Y Y Y Y Y Y Y Y Y Y N NFSR Y Y Y Y Y Y Y Y Y Y N N
F2 - Prioritise FSR Y Y Y Y N Y Y Y Y Y Y N NFSR Y Y Y Y N Y Y Y Y Y Y N N
F3 - Categorise FSR Y Y Y Y N Y Y Y Y Y Y N NFSR Y Y Y Y N Y Y Y Y Y Y N N
F4 - Assign FSR FSR Y Y Y Y Y Y Y Y Y Y N NEmail Receipt Y Y Y Y Y Y Y Y Y Y N N
Fig. 8.11. Incident Management Process - Input & Output Quality Dimension (After Valida-tion)
During the workshop, the key stakeholders were asked to select a Boolean
value (Yes/No) in each cell of the matrix to specify whether a quality char-
acteristic is important for the human resource allocated to a function.
Domain Knowledge Qualification Certification Experience Time Manage
mentCommunication Skill Leadership TotalClassify FSR Y Y Y Y 4Priorities FSR Y Y Y 3Categorise FSR Y Y Y 3Assign FSR Y Y Y Y 4Total 4 0 0 4 4 2 0
Fig. 8.12. Incident Management Process - Human Resource Quality Dimension
The outcome of the third workshop was the table presented in Fig-
ure 8.12. Each row of this table represents a function of the incident man-
agement process and the columns represent quality characteristics of human
resource dimension. Where a quality characteristic is relevant to the func-
tion then a Y (for yes) is present in the appropriate cell. The totals in a
row represents the number of quality characteristics relevant to the func-
tion in that row. For example, totals of 3 for the function categorise FSR
indicates that 3 quality characteristics out of 7 are relevant and important
252 8
to this function. By viewing this table it was easy for the key stakeholders
to identify the resources that play an important role in the quality of the
process. The column totals are indicators on the relevancy of each quality
characteristic in the whole process. For example, domain knowledge, expe-
rience, and time management have the highest totals (4) which indicates
that these quality characteristics are very important for the process. On
contrary, qualification, certification and leadership which have the lowest
total (0) indicates that they are not of significant importance to this pro-
cess.
00.511.522.533.54Classify FSR Prioritise FSR Categorise FSR Assign FSR
Fig. 8.13. Incident Management Process - Human Resource Quality Rating
In this instance, the resource responsible for the functions: classify FSR
(4), and assign FSR (4) scored the highest ratings therefore play a more sig-
nificant role in the quality outcomes for the incident management process.
This exercise also identified that the resources responsible for the functions
categorise FSR (3), and prioritise FSR (3) play a less important role in the
quality outcomes for the incident management process. These results are
displayed graphically in Figure 8.13.
Also, the quality characteristics: domain knowledge (4), experience (4),
and time management (4) scored the highest ratings therefore highlight-
8.4 253
00.511.522.533.54
Fig. 8.14. Incident Management Process - Quality Characteristics
ing these characteristics as more important for this process. This exercise
also identified that certification (0), qualification (0), and leadership (0) are
less important characteristics for this process. These results are displayed
graphically in Figure 8.14.
The following sub-section presents the outcome of the fourth workshop
conducted to model the non-human resource quality dimension of the inci-
dent management process.
Non-Human Resources Quality Dimension
The purpose the fourth workshop was to identify the quality characteristics
of the non-human resource dimension of the incident management process.
During the workshop, the researcher created a quality model for the non-
human resource dimension of the incident management process using the
QoBP automation tool which was reviewed by the key stakeholders.
The outcome of this workshop was an automatically generated non-
human resource quality model for the incident management process which
is presented in Figure 8.15.
254 8
Suita
bility
Accu
racy
Secu
rity
Relia
bility
Unde
rstan
dabil
ity
Learn
abilit
y
Time b
ehav
iour e
fficien
cy
Reso
urce u
tilisat
ion
Effec
tiven
ess
Produ
ctivit
y
Safet
y
Satis
factio
n
Robu
stnes
s
Classify FSR Helpdesk System 2 3 1Priorities FSR Helpdesk System 2 1 3Categorise FSR Helpdesk System 2 1 3Assign FSR Helpdesk System 2 3 1
Total 6 5 0 3 0 0 4 0 6 0 0 0 0
Fig. 8.15. Incident Management Process - Non Human Resource Quality Dimension (by rows- quality characteristics)
02468101214
Fig. 8.16. Incident Management Process - Non Human Resource Quality Rating
The totals obtained for each quality characteristic by this approach high-
light that the quality characteristics suitability (6) and effectiveness (6) is
the significant quality characteristics for the incident management process.
Also the quality characteristics: security (0), understandability (0), learn-
ability (0), resource utilisation (0), productivity (0), satisfaction (0), robust-
ness (0), and safety (0) play a less important role in the quality outcomes
for the incident management process. These results are displayed graphi-
cally in Figure 8.16.
8.4 255
The next step after creating the quality model for the incident manage-
ment process is to create a softgoal model which is presented below.
8.4.4.4 Step 4 - Create Softgoal Model
The purpose of this step was to create a softgoal model for the incident
management process9. During this step, the researcher created a softgoal
model for the incident management process using the QoBP automation
tool. This model was reviewed and altered by the key stakeholders during
four workshops. The researcher followed the methodology and guidelines
provided by the action research protocol presented in Chapter 5.3.4.1.4.
The outcome of the first workshop was a softgoal model for the function
quality dimension which is presented in Appendix E.1. The softgoal model
for the input & output quality dimension that was created during the second
workshop is presented in Appendix E.2. The softgoal model for the human
resource quality dimension that was created during the third workshop is
presented in Appendix E.3. Finally, the outcome of the fourth workshop
was a softgoal model for the non-human resource quality dimension which
is presented in Appendix E.4.
The following section outlines the next activity conducted during the
action taking stage of the of the action research cycle in Organisation C.
8.4.4.5 Step 5 - Create Softgoal Correlations Model
The purpose of this step was to create a correlation model for the incident
management process10. During this step, the researcher created a softgoal
correlation model for the incident management process using the QoBP au-
tomation tool. The outcome of this step was a softgoal correlation model
for the incident management process which is presented in Appendix E.5.
9 Refer to Sections 4.4.2 and 4.4.6.4 for further details on the softgoal correlation model.10 Refer to Sections 4.4.3 and 4.4.6.5 for further details on the softgoal correlation model.
256 8
The following section outlines the last activity conducted during the ac-
tion taking stage of the action research cycle in Organisation C.
8.4.4.6 Step 6 - Create Measurement Model
The purpose of this step was to create a measurement model for the incident
management process11. The measurement model contains the measurable
attributes (referred to as quality metrics) that are identified to evaluate the
quality characteristics of the business process that are modelled in the form
of softgoals. As described in Section 4.4.4, this research adopts an approach
similar to the GQM [147] approach in refining softgoals to a set of quality
metrics. Each softgoal is refined into a set of questions and then each ques-
tion is refined into a set of quality metrics.
During this step, the researcher conducted four workshops with the key
stakeholders to create a measurement model which contains quality met-
rics required to measure softgoal satisfaction for the softgoal model created
for the incident management process. During the workshops, the researcher
followed the methodology and guidelines provided by the action research
protocol presented in Chapter 5.3.4.1.6.
The outcome of the first workshop was a measurement model for the
function quality dimension which is presented in Appendix E.6. The mea-
surement model for the input & output quality dimension that was created
during the second workshop is presented in Appendix E.7. The measurement
model for the human resource quality dimension that was created during
the third workshop is presented in Appendix E.8. Finally, the outcome of
the fourth workshop was a measurement model for the non-human resource
quality dimension which is presented in Appendix E.9.
The following section outlines the activities performed during the second
phase of the action taking stage.
11 Refer to Sections 4.4.4, and 4.4.6.6 for further details on the measurement model.
8.4 257
8.4.5 Action Taking - Phase II
This section presents the activities performed during the second phase of
the action taking stage which was dedicated to the quality improvement
phase of the quality-aware BPM life cycle. As described in Section 8.4.3,
the aim of this phase was to use the PRCA technique to identify the root
cause of the recurring quality issue with the incident management process
(identified in Section 8.4.2).
In order to trace a quality issue back to its root cause for an instance of
a business process, the correlations between softgoals that are modelled in
a softgoal correlation model for the process12 are used. Figure 8.17 depicts
a graphical representation of the softgoal correlation model for the incident
management process that is exhibited in Appendix E.5. The PRCA tech-
nique consists of several steps that were described in Section 4.5.2.
The researcher organised four workshops to perform root cause anal-
ysis using the PRCA technique. During the first workshop the recurring
poor quality incident management case was reviewed with the relevant key
stakeholders in order to articulate the quality issue(s). As it was stated in
the email by the head of the division affected by this recurring issue, the
support for the recurring incident (problem with processing of the batch
files) was not addressed in a timely manner. The quality issue with these
two incident management instances was articulated as poor time efficiency.
The next three workshops were allocated to the investigation of these two
process instances. During these workshops, the researcher followed the step-
by-step procedure provided in Section 4.5.2 and the guidelines provided by
the action research protocol presented in Section 5.3.4.2.
First the softgoals associated with the quality issue13 was identified which
was Softgoal 60 (to improve the time behaviour efficiency of the Assign FSR
function). The softgoal correlation model created for the incident manage-
ment process (Figure 8.17) was used to trace softgoal 60 to its correlated
softgoals14. The traced softgoals were then evaluated using the measurement
12 The softgoal correlation model for the incident management was presented in Section 8.4.4.5.13 First step of the PRCA technique presented in Section 4.5.2.14 Second step of the PRCA technique presented in Section 4.5.2.
258 8
� Softgoal 14 - To improve the domain knowledge of the Help Desk Officer performing the ‘Classify FSR’ function.� Softgoal 15 - To improve the time management skill of the Help Desk Officer performing the ‘Classify FSR’ function.� Softgoal 16 - To increase the experience of the Help Desk Officer performing the ‘Classify FSR’ function.
� Softgoal 1: To increase the suitability of the function “Classify FSR” function.� Softgoal 2 - To improve the accuracy of the ‘Classify FSR’ function.� Softgoal 3 - To improve the time behaviour efficiency of the ‘Classify FSR’ function.
Human Resource: Help Desk Officer
Function F1: Classify FSR
� Softgoal 4 - To improve the accuracy of the ‘FSR’ data of the ‘Classify FSR’ function.� Softgoal 5 - To improve the objectivity of the ‘FSR’ data of the ‘Classify FSR’ function.� Softgoal 6 - To improve the believability of the ‘FSR’ data of the ‘Classify FSR’ function.� Softgoal 7 - To improve the reputation of the ‘FSR’ data of the ‘Classify FSR’ function.� Softgoal 8- To improve the relevancy of the ‘FSR’ data of the ‘Classify FSR’ function.� Softgoal 9 - To increase the added value of the ‘FSR’ data of the ‘Classify FSR’ function.� Softgoal 10 - To improve the timeliness of the ‘FSR’ data of the ‘Classify FSR’ function.� Softgoal 11 - To improve the completeness of the ‘‘FSR’ data of the ‘Classify FSR’ function.� Softgoal 12 -To improve the amount of data of the ‘FSR’ data of the ‘Classify FSR’ function.� Softgoal 13 - To improve the understandability of the ‘FSR’ data of the ‘Classify FSR’ function.
Input/Output: FSR
� Softgoal 17 - To improve the suitability of the Help Desk System performing the ‘Classify FSR’ function.� Softgoal 18 - To improve the accuracy of the Help Desk System performing the ‘Classify FSR’ function.� Softgoal 19 - To improve the time behaviour efficiency of the Help Desk System performing the ‘Classify FSR’ function.
Non- Human Resource: Help Desk System
� Softgoal 33 - To improve the domain knowledge of the Help Desk Officer performing the ‘Prioritise FSR’ function.� Softgoal 34 - To improve the time management skill of the Help Desk Officer performing the ‘Prioritise FSR’ function.� Softgoal 35 - To increase the experience of the Help Desk Officer performing the ‘Prioritise FSR’ functi on.
� Softgoal 20: To improve the suitability of the ‘Prioritise FSR’ function.�� Softgoal 21 - To improve the time behaviour efficiency of the ‘Prioritise FSR’ function.�� Softgoal 22 - To improve the effectiveness of the ‘Prioritise FSR’ function.
Human Resource: Help Desk Officer
� Softgoal 23 - To improve the accuracy of the ‘FSR’ data of the ‘Prioritise FSR’ function.� Softgoal 24 - To improve the objectivity of the ‘FSR’ data of the ‘Prioritise FSR’ function.� Softgoal 25 - To improve the believability of the ‘FSR’ data of the ‘Prioritise FSR’ function.� Softgoal 26 - To improve the reputation of the ‘FSR’ data of the ‘Prioritise FSR’ function.� Softgoal 27- To improve the relevancy of the ‘FSR’ data of the ‘Prioritise FSR’ function.� Softgoal 28 - To increase the added value of the ‘FSR’ data of the ‘Prioritise FSR’ function.� Softgoal 29 - To improve the timeliness of the ‘FSR’ data of the ‘Prioritise FSR’ function.� Softgoal 30 - To improve the completeness of the ‘FSR’ data of the ‘Prioritise FSR’ function.� Softgoal 31 -To improve the amount of data of the ‘FSR’ data of the ‘Prioritise FSR’ function.� Softgoal 32 - To improve the understandability of the ‘FSR’ data of the ‘Prioritise FSR’ function.
Input/Output: FSR
� Softgoal 36 - To improve the suitability of the Help Desk System performing the ‘Prioritise FSR’ function.� Softgoal 37 - To improve the time behaviour efficiency of the Help Desk System performing the ‘Prioritise FSR’ function.� Softgoal 38 - To improve the effectiveness of the Help Desk System performing the ‘Prioritise FSR’ function.
Non- Human Resource: Help Desk System
Function F2: Prioritise FSR
� Softgoal 39: To improve the suitability of the ‘Categorise FSR’ function.� Softgoal 40 - To improve the time behaviour efficiency of the ‘Categorise FSR’ function.� Softgoal 41 - To improve the effectiveness of the ‘Categorise FSR’ function.
Function F3: Categorise FSR
� Softgoal 58 -To improve the accuracy of the ‘Assign FSR’ function.� Softgoal 59 - To improve the reliability of the ‘Assign FSR’ function.� Softgoal 60 - To improve the time behaviour efficiency of the ‘Assign FSR’ function.
Function F4: Assign FSR
� Softgoal 42 - To improve the accuracy of the ‘FSR’ data of the ‘Categorise FSR’ function.� Softgoal 43 - To improve the objectivity of the ‘FSR’ data of the ‘Categorise FSR’ function.� Softgoal 44 - To improve the believability of the ‘FSR’ data of the ‘Categorise FSR’ function.� Softgoal 45 - To improve the reputation of the ‘FSR’ data of the ‘Categorise FSR’ function.� Softgoal 46- To improve the relevancy of the ‘FSR’ data of the ‘Categorise FSR’ function.� Softgoal 47 - To increase the added value of the ‘FSR’ data of the ‘Categorise FSR’ function.� Softgoal 48 - To improve the timeliness of the ‘FSR’ data of the ‘Categorise FSR’ function.� Softgoal 49 - To improve the completeness of the ‘FSR’ data of the ‘Categorise FSR’ function.� Softgoal 50 - To improve the amount of data of the ‘FSR’ data of the ‘Categorise FSR’ function.� Softgoal 51 - To improve the understandability of the ‘FSR’ data of the ‘Categorise FSR’ function.
Input/Output: FSR
� Softgoal 58 - To improve the accuracy of the ‘FSR’ data of the ‘Assign FSR’ function.� Softgoal 59 - To improve the objectivity of the ‘FSR’ data of the ‘Assign FSR’ function.� Softgoal 60 - To improve the believability of the ‘FSR’ data of the ‘Assign FSR’ function.� Softgoal 61 - To improve the reputation of the ‘FSR’ data of the ‘Assign FSR’ function.� Softgoal 62- To improve the relevancy of the ‘FSR’ data of the ‘Assign FSR’ function.� Softgoal 63 - To increase the added value of the ‘FSR’ data of the ‘Assign FSR’ function.� Softgoal 64 - To improve the completeness of the ‘FSR’ data of the ‘Assign FSR’ function.� Softgoal 65 - To improve the amount of data of the ‘FSR’ data of the ‘Assign FSR’ function.� Softgoal 66 - To improve the understandability of the ‘FSR’ data of the ‘Assign FSR’ function.
Input/Output: FSR
� Softgoal 67 - To improve the accuracy of the ‘Email Receipt’ data of the ‘Assign FSR’ function.� Softgoal 68 - To improve the objectivity of the ‘Email Receipt’ data of the ‘Assign FSR’ function.� Softgoal 69 - To improve the believability of the ‘Email Receipt’ data of the ‘Assign FSR’ function.� Softgoal 70 - To improve the reputation of the ‘Email Receipt’ data of the ‘Assign FSR’ function.� Softgoal 71- To improve the relevancy of the ‘Email Receipt’ data of the ‘Assign FSR’ function.� Softgoal 72 - To increase the added value of the ‘Email Receipt’ data of the ‘Assign FSR’ function.� Softgoal 73 - To improve the completeness of the ‘Email Receipt’ data of the ‘Assign FSR’ function.� Softgoal 74 - To improve the amount of data of the ‘Email Receipt’ data of the ‘Assign FSR’ function.� Softgoal 75 - To improve the understandability of the ‘Email Receipt’ data of the ‘Assign FSR’ function.
Output: Email Receipt
� Softgoal 52 - To improve the domain knowledge of the Help Desk Officer performing the ‘Categorise FSR’ function.� Softgoal 53 - To increase the experience of the Help Desk Officer performing the ‘Categorise FSR’ function.� Softgoal 54 - To improve the time management skill of the Help Desk Officer performing the ‘Categorise FSR’ function.
Human Resource: Help Desk Officer
� Softgoal 76 - To improve the domain knowledge of the Help Desk Officer performing the ‘Assign FSR’ function.� Softgoal 77 - To increase the experience of the Help Desk Officer performing the ‘Assign FSR’ function.� Softgoal 78 - To improve the time management skill of the Help Desk Officer performing the ‘Assign FSR’ function.� Softgoal 79 - To improve the communication skill of the Help Desk Officer performing the ‘Assign FSR’ function.
Human Resource: Help Desk Officer
� Softgoal 55 - To improve the suitability of the Help Desk System performing the ‘Categorise FSR’ function.� Softgoal 56 - To improve the time behaviour efficiency of the Help Desk System performing the ‘Categorise FSR’ function.� Softgoal 57 - To improve the effectiveness of the Help Desk System performing the ‘Categorise FSR’ function.
Non- Human Resource: Help Desk System
� Softgoal 80 - To improve the accuracy of the Help Desk System performing the ‘Assign FSR’ function.� Softgoal 81 - To improve the reliability of the Help Desk System performing the ‘Assign FSR’ function.� Softgoal 82 - To improve the time behaviour efficiency of the Help Desk System performing the ‘Assign FSR’ function.
Non- Human Resource: Help Desk System
First correlations
Second correlations
Third correlations
Fig. 8.17. Softgoal Correlations - Incident Management Process
model created for the incident management15 process and the evaluation
15 Section 8.4.4.6 presented the measurement model created for the incident management pro-cess.
8.4 259
results were recorded in the template provided by the action research pro-
tocol (see Section 5.3.4.2). The last two steps were repeated until no more
softgoals could be traced. Using the provided template, the evaluation re-
sults were grouped by functions that the traced softgoals belonged to. The
traced softgoals for four functions of the incident management process were
evaluated. Each softgoal was evaluated through the evaluation of the met-
rics defined for that softgoal in the measurement model. Each metric was
evaluated against the threshold value specified for that metric in the mea-
surement model. After all traced softgoals were evaluated, the root cause
of the quality issue was identified by investigating the last softgoal being
traced which was not satisfied.
The evaluation results for the two investigated instances are presented
in Appendix E.10, and Appendix E.11. The investigations of these two in-
stances revealed that these two incidents where handled by the same Help
Desk Officer who recently joined Organisation C (3 months ago). He had
about 3 years of experience as a Help Desk Officer in other organisations,
but his industry knowledge (Organisation C related knowledge) was lim-
ited. The root quality issue being identified during the root cause analysis
process was linked to softgoal 3 (to improve the time behaviour efficiency
of the Classify FSR function). This softgoal was not satisfied, because the
turnaround time to perform the classify FSR function exceeded its accept-
able threshold values of < 5 minutes. Further investigation of the softgoals
linked to the root quality issue revealed that the Help Desk Officer ’s lack of
knowledge on call type definitions affected his decision making ability, lead-
ing to failure of two other softgoals contributing to the root quality issue:
softgoal 14 (to improve the time management skill of the Help Desk Officer
performing the Classify function) and softgoal 15 (to increase the experience
of the Help Desk Officer performing the Classify FSR function). Softgoal 15
was not satisfied due to its quality metric (decision making duration) not
meeting the threshold value. It took more time than was acceptable for the
Help Desk Officer to make a decision on classifying the FSR because he only
had a basic knowledge of the call type definitions of Organisation C (the
acceptable threshold value for call type definition knowledge was interme-
diate). The evaluation results from two instances confirmed the same root
260 8
cause. Whilst a gradual improvement on time efficiency was shown from the
first case to the second case, the process was still not meeting its threshold
values for acceptable turnaround time.
The identified root causes were shared with the head of the IT Support
team and the head of the business division affected by the recurring quality
issue. The head of the IT Support team formulated a strategy based on the
provided data to prevent the reoccurrence of this quality issue. This strat-
egy involved the implementation of the quality-aware incident management
process created as part of this action research cycle. By implementing the
quality-aware incident management process, the quality of the future in-
stances could be controlled in a proactive way. For example, an incident
that requires urgent attention will be allocated to a Help Desk Officer who
meets all the threshold values for the quality metrics contributing to the
time efficiency quality characteristic.
The following section outlines a summary of the next step of the action
research cycle in which the outcome of the activities performed during the
action taking stage was evaluated.
8.4.6 Evaluation
The main purpose of this stage was to evaluate the usability, usefulness, and
scalability of the QoBP framework and the PRCA technique used during the
action taking stage of this cycle. To ensure the rigor of the evaluation phase
of this study16, a set of evaluation objectives were developed and presented
in Section 5.3.5. The action research protocol also provided a questionnaire
that was created based on these evaluation objectives17.
During this step, the researcher conducted a series of workshops to eval-
uate the outcome of the action research with the Project Manager. The
main purpose of the evaluation stage of the action research cycle was ex-
plained to the the Project Manager at the beginning of the workshop series.
16 Refer to guideline 5 - research rigor [2] described in Section 3.6.17 This questionnaire is provided in Appendix B.5.
8.4 261
The questionnaire provided by the action research protocol was used to
guide the discussions during the workshops. The researcher followed the
three communication behaviours recommended in [184] to ensure that each
evaluation objective was communicated effectively. The outcome of the eval-
uation workshop, with respect to the evaluation objectives, include:
• Quality model:
– Applicability of the quality characteristics defined for the four quality
dimensions (function quality dimension, input & output quality di-
mension, human resource quality dimension, and non-human resource
quality dimension) of the quality model was confirmed. The objectives
here was to validate that the quality characteristics for the four dimen-
sions are relevant and applicable to business processes. While these
quality characteristics were defined based on an extensive literature
review in related areas, and their applicability was confirmed twice
during the first and second action research cycles, it was important
to evaluate their applicability during the third action research cycle.
The relevancy and the appropriateness of each quality characteristic
with respect to its quality dimension was reviewed during the evalua-
tion workshops and was acknowledged by the workshops participants.
Comments from the workshop participants include: “...the provided
list of quality characteristics covered all our quality requirements...the
list also prompted us to think about quality aspects that we hadn’t
previously considered...”.
– Usability and scalability of the QoBP methodology, QoBP automa-
tion tool and the supporting templates to identify and capture the
quality characteristics for the four quality dimensions of the selected
business process was confirmed. The usability and scalability limita-
tions of the QoBP methodology to capture the quality characteristics
for the input & output dimension that was identified during the first
cycle of the action research18, was rectified by introducing the QoBP
18 Refer to Section 6.4.5 for further details on the evaluation results of the first action researchresults.
262 8
automation tool. Comments from the workshop participants include:
“...the three different spreadsheets helped us to view the quality as-
pects from different angles...the tool was helpful in producing a list as
the starting point...”.
• Softgoal model:
– Applicability of the softgoal model of the QoBP framework was con-
firmed by the workshop participants. It was acknowledged that the
goal-oriented approach adopted in this research is a relevant and ap-
propriate approach in coping with the abstract and informal nature
of non-functional requirements in the form of quality characteristics.
Comments from the workshop participants confirming the applicabil-
ity of the softgoal model include: “...the softgoals played an impor-
tant role in making the quality characteristics more meaningful...it
provided extra context for each quality characteristic...”.
– Practicality and scalability of the QoBP methodology, and the QoBP
automation tool to identify softgoals for the identified quality charac-
teristics for the incident management process was confirmed. Starting
with a generic softgoal model that was created automatically using the
QoBP automation tool and making any necessary alterations during
the workshops did certainly improve the scalability and practicality
of the QoBP framework. Comments from the workshop participants
include: “...it was good to start with an automatically created list of
softgoals, but the re-phrasing the softgoals can still be a lot of work...”.
• Softgoal correlation model:
– Practicality and scalability of the QoBP methodology and the QoBP
automation tool to model the correlations between identified soft-
goals was confirmed. The scalability issue that was identified during
the second action research cycle (see Section 7.4.5) was rectified by
introducing the QoBP automation tool. Comments from the work-
shop participants include: “...no effort was required from us which
8.4 263
was great...”.
• Measurement model:
– Practicality and scalability of the QoBP methodology and the sup-
porting templates to create a measurement model was confirmed. It
was also acknowledged that the goal-question-metric approach was
very effective in refining each softgoal to a set of quality metrics as
it was providing a structured approach that while being efficient, it
was easy to follow. Comments from the workshop participants include:
“...having a step-by-step approach to determine the metrics from soft-
goals was beneficial...the phrasing of the questions make it easier to
define the appropriate metrics...”.
• QoBP Metamodel:
– Validity of the QoBP metamodel proposed in Section 4.4.5.2 in pro-
ducing a quality-aware business process was confirmed. This objective
was met, as it was acknowledged that the QoBP metamodel captures
the necessary entities to produce a quality-aware business process.
Comments from the workshop participants include: “...the way the
model covered all the components of the business process gave us
comfort that all quality related items were captured and concisely ex-
pressed...”.
• PRCA Technique:
– Comprehensiveness of the PRCA technique was confirmed. The PRCA
technique provided the key stakeholders conducting the investigation
with the ability to identify the sequence of events leading to the root
causes of a recurring quality issue in the incident management pro-
cess. Using the PRCA technique enabled the investigators to trace
the recurring quality issue to its root issue and causes of the root is-
sue. Comments from the Help Desk Officer include: “...this technique
264 8
helped us isolate the underlying issue and trace it back to its causes...”.
– Context-awareness of the PRCA technique was confirmed. The PRCA
technique provided the key stakeholders conducting the investigation
the context required to conduct corrective action. Comments from the
Project Manager include: “...afer identifying the underlying issue (call
definition knowledge level type) we were able to determine the major
contributing factor to the problem...this helped us plan how to correct
the underlying cause...”.
– The PRCA technique provided a systematic methodology to conduct
the investigation. Comments from the workshop participants include:
“it provided a step-by-step procedure to detect the root causes of the
recurring issue...”.
– It was confirmed that the PRCA technique is easy to learn and is
easy to use. The only concern was the scalability of the approach for
larger processes. Comments from the workshop participants include:
“...while the technique was easy to learn and easy to use, this ap-
proach could possibly be improved by automating the process...”.
During the last evaluation workshop it was also acknowledged by the
Project Manager that:
“...the improvement to the incident management process without con-
sidering the quality requirements was limited ...because our focus was only
on functional requirements not quality requirements...”
“...this exercise also changed our attitude towards defining process KPIs
(Key Performance Indicators) for board reports which have always been
around process cost and delivery time...the quality characteristics can help
us to report KPIs that are more quality focused...”
8.4 265
The following section outlines the next step of the first action research -
the identification of the lessons learned from the action research cycle.
8.4.7 Specifying Learning
The purpose of this step was to identify the lessons learned during the third
action research cycle. The evaluation results produced during the last stage
strongly influenced the discovery of the lessons learned and the possible
enhancements to the framework. During this stage, the researcher organised
a workshop with the Project Manager to reflect on the evaluation results
described in the previous section. The outcome of the first workshop can be
summarised as:
1. Development of a tool to automate the PRCA technique - The possi-
bility of the automation of the PRCA technique was discussed during
the workshop. The scalability of the PRCA technique could be an issue
for large business processes. The accuracy of the approach could also
be an issue where a large number of softgoals are required to be traced
and evaluated. It was discussed how the automation will improve the
scalability and the accuracy of the PRCA technique.
2. Effectiveness of the PRCA technique - The effectiveness of the PRCA
technique may be affected when there is a limit on the number of char-
acteristics that can be selected. As described in Section 5.3.4.1.3, a limit
on the number of function quality characteristics can be selected based
on the project’s constraints. The limit on the number of function qual-
ity characteristics for the incident management for example was three.
This limits the number of softgoals and quality metrics identified for the
process. Therefore the softgoal correlation model and the measurement
model created for the process are not as comprehensive as it should be.
To make the PRCA technique more effective for a business process, all
the relevant function quality characteristics are required to be selected
and modelled in the quality model of the process.
Next section presents a summary of the final stage of the action research
cycle with Organisation C - closure.
266 8
8.4.8 Closure
During this last stage of the action research, the researcher organised an
informal meeting to express her appreciation to the key stakeholders con-
tributing to this collaborative project.
8.5 Summary of the Third Action Research Cycle
The chapter described the third cycle of the action research conducted as
part of this study. During this cycle the enhancements made to the QoBP
framework and the QoBP methodology as a result of the first and second
action research cycles (see Sections 6.4.6, and 7.4.6) were evaluated for the
second time. The PRCA technique was also evaluated in this action re-
search cycle. The evaluation of this action research cycle was presented in
Section 8.4.6. Section 8.4.7 outlined the learning from this cycle , and the
enhancements made to the artifacts as a result. The objectives of the third
action research cycle was met.
8.6 Summary of the Action Research Phase (Part III)
This chapter concludes Part III of this thesis which was dedicated to action
research. Action research conducted in professional manner, in accordance
with the action research protocol provided in Chapter 5. The workshops
conducted during the action research cycles did not exactly follow the time-
line and number of sessions recommended in the action research due to key
participants’ commercial priorities. Action research cycles were conducted
in an evolutionary manner with each action research case providing an op-
portunity to mature the QoBP framework and its associated artifacts. The
QoBP automation tool developed after the first action research cycle is an
example of the evolutionary enhancements to the framework leading to fur-
ther contributions.
A summary of the three action research cycles is presented in Figure 8.18
which provides the list of the artifacts evaluated during each cycle, the
8.6 267
Artifact Evaluated
Recommended Enhancement
Enhancement ImplementedQuality Model Establish link between quality dimensions YesSoftgoal Model None NoneSoftgoal Correlation Model None NoneMeasurement Model None NoneQoBP Metamodel None NoneDevelop QoBP automation tool to enhance the usability and scalability of the QoBP methodology YesFormulate new strategies on efficient data/information collection YesQuality Model None NoneSoftgoal Model Create a generic softgoal model YesSoftgoal Correlation Model None NoneMeasurement Model None NoneQoBP Metamodel None NoneEnhance the QoBP methodology by automating the creation of a generic softgoal model YesEnhance the QoBP methodology by automating the creation of a softgoal correlation model YesEnhance the QoBP automation tool to create a generic softgoal model automatically YesEnhance the QoBP automation tool to create a softgoal correlation model automatically YesQuality Model Enhance the strategy by not limiting the number of selected quality characteristics YesSoftgoal Model None NoneSoftgoal Correlation Model None NoneMeasurement Model None NoneQoBP Metamodel None NoneQoBP Methodology None NoneQoBP Automation Tool Enhance the QoBP automation tool to conduct root cause analysis automatically NonePRCA Technique Enhance the scalability and accuracy of the PRCA technique by automating the root cause analysis None
Case Two
Case Three
QoBP Methodology
QoBP Methodology QoBP Automation Tool
Case One
Fig. 8.18. Summary of the Action Research Cycles
recommendations made during the specifying learning stage of each cycle
and the confirmation on whether the enhancement was implemented.
9
Research Contributions, Limitations and
Outlook
9.1 Introduction
The chapter concludes this thesis by providing an overview of this study,
a summary of the contributions, a brief look at the limitations and some
insights into future research opportunities.
The study was motivated by the lack of an appropriate framework for
organisations to manage the quality of business processes during different
phases of the BPM life cycle. It addressed four research questions which
are re-visited in the next section. The study employed a multi-method re-
search design based on the design science approach and the action research
methodology. During the design science phase, artifacts were developed to
address the research questions. These artifacts were then evaluated through
three cycles of action research which were conducted within three large
Australian-based organisations.
The major theoretical and practical contributions and implications of
this study are presented in Section 9.3. In summary, this thesis contributes
to the body of BPM knowledge by:
• Proposing a quality-aware BPM life cycle that provides a framework
for incorporating quality into a business process and subsequently man-
aging quality during the BPM life cycle.
• Providing a framework (QoBP framework) to capture and model qual-
ity requirements of a business process as a set of measurable elements
270 9
that can be incorporated into the business process model. The QoBP
framework includes the quality characteristics for four dimensions of a
business process. It also includes the softgoal model, the softgoal corre-
lation model, the measurement model, and the QoBP metamodel. The
QoBP framework also provides a well developed methodology with sup-
porting templates for ease of use.
• Providing an automation tool (QoBP automation tool) which proved
that the QoBP framework lends itself to an automated solution.
• Proposing a root cause analysis technique (PRCA technique) to de-
termine the root causes of quality issues within business processes.
As with any other research, this study has faced limitations presented by
the methods selected, the availability of participants, researcher bias and so
on. These limitations and the efforts made to minimise them are presented
in Section 9.4. This study has also provoked more questions than can be
addressed during the subsequent research activities. These future research
opportunities are presented in Section 9.5 which concludes this chapter.
9.2 Re-visiting Research Questions
The purpose of this section is to revisit the research questions and to briefly
discuss how these questions were addressed. The managerial question driv-
ing this study was: “How can organisations manage the quality of
business processes during the different phases of the BPM life
cycle?”. Figure 9.1 presents a summary of the research questions and the
artifacts developed to address theses questions. Further details on how these
questions were addressed is provided below.
How can quality be incorporated into a business process and man-
aged during the BPM life cycle?
A detailed literature review was conducted in the areas of BPM (Sec-
tion 2.2.3) and quality (Section 2.3.1) to develop a quality management
model for BPM. Section 2.3.4 presented the first finding of this effort, where
a quality management model, which is suitable to be incorporated into the
9.2 271
Research Question Proposed Artifact (s) Reference
How can quality be incorporated into a business process and managed during the BPM life cycle?
Quality Aware BPM Life Cycle Section 4.2
What are the business process quality dimensions? QoBP Framework - Quality Model Section 4.3
How can quality be incorporated into a business process model producing a quality-aware business process?
QoBP Framework - Softgoal Model QoBP Framework - Softgoal Correlation Model QoBP Framework - Measurement Model QoBP Framework - QoBP Metamodel QoBP Framework - QoBP Methodology QoBP Framework - QoBP Automation Tool
Section 4.4
What is a suitable root cause analysis technique for identifying the root causes of the quality issues of a business process?
PRCA Technique Section 4.5
Fig. 9.1. Research Questions & Proposed Artifacts
BPM life cycle, was proposed. The proposed quality management model
consists of four key phases of quality definition, quality implementation,
quality control and quality improvement. Section 4.2 addressed the main
research question by introducing the quality-aware BPM life cycle in which
our proposed quality management model is incorporated into the BPM life
cycle. In the quality-aware BPM life cycle, the quality of a business process
is managed based on the four key phases of quality definition, quality im-
plementation, quality control, and quality improvement.
This stage of the study has revealed several sub-questions to the main re-
search question outlined above which are related to the quality-aware BPM
life cycle. As described previously, the scope of this research was limited to
provide supporting artifacts for the first and last phases of the quality-aware
BPM life cycle: quality definition and quality improvement.
What are the business process quality dimensions?
The first sub-question is related to the quality definition phase. This was
addressed in Section 4.3 where the quality model was proposed. Four di-
mensions of the quality model, function, input & output, human resource,
272 9
and non-human resource quality dimensions, were described in detail in
Section 4.3.2. This section also introduced the Quality of Business Pro-
cess (QoBP) framework in which the quality model was utilised to create a
quality-aware business process model during the quality definition phase of
the quality-aware BPM life cycle.
The four dimensions of the quality model were evaluated during the ac-
tion research phase of this study which consisted of three action research
cycles. Comprehensive reports for these three cycles were presented in Chap-
ters 6, 7, and 8. The evaluation proved in all cycles that the quality char-
acteristics were relevant and the appropriate with respect to their quality
dimensions.
How can quality be incorporated into a business process model
producing a quality-aware business process?
The second research sub-question, related to the quality definition phase
of the quality-aware BPM life cycle. This question was addressed by the
Quality of Business Process (QoBP) framework proposed in Sections 4.3
and 4.4. Section 4.4 presented how in the QoBP framework, the quality
model proposed in Section 4.3 is utilised to create a quality-aware business
process model. The QoBP framework supports a goal-driven measurement
approach which is based on three models: softgoal model, softgoal correlation
model, and measurement model. The softgoal model represents the quality
characteristics of a quality model as a set of softgoals. The softgoal cor-
relation model represents the relationships between the specified softgoals.
The measurement model represents how quality characteristics that are de-
scribed in the form of softgoals are evaluated. To be able to embed these
models into a business process model, an extension to the EPC notation
was proposed in Section 4.4.5.2.
A supporting methodology was also provided as part of the QoBP frame-
work. This methodology provided a step-by-step procedure and templates
to create a quality-aware business process model. The QoBP framework
models and methodology were evaluated during the action research phase
of this study which consisted of the three action research cycles. Compre-
9.2 273
hensive reports for these three cycles were presented in Chapters 6, 7, and
8. In all cycles, the models of the QoBP framework proved to be applicable,
appropriate, and useful in creating a quality-aware business process model.
The evaluation in the first cycle confirmed that the creation of the quality
model was too time consuming. The QoBP automation tool was developed
to overcome this problem and enhance the QoBP methodology. The eval-
uation in the second cycle revealed that a generic softgoal model can be
provided as part of the QoBP framework. A generic softgoal model was
created to be used as a starting point. The creation of the generic softgoal
model led to further enhancements to the QoBP automation tool and the
QoBP methodology respectively. The QoBP automation tool was enhanced
to automate the generation of the softgoal and softgoal correlation models.
What is a suitable analysis technique for identifying the root
causes of the quality issues of a business process?
The third research sub-question related to the quality improvement phase
of the quality-aware BPM life cycle was. This question was addressed by the
PRCA technique proposed in Section 4.5. The PRCA technique is a novel
root cause analysis approach for business processes. The PRCA technique
utilises the softgoal correlation model to identify the root causes of a quality
issue in an instance of a business process.
The PRCA technique was evaluated during the third action research cy-
cle of the action research phase of this study. A comprehensive report for
the third action research cycle was presented in Chapter 8. The technique
was found to be systematic, comprehensive, context-aware, and easy to use.
For larger processes, part of the technique could be automated.
Thus, the study outcomes have addressed the managerial question “How
organisations can manage the quality of business processes during the dif-
ferent phases of the BPM life cycle?” by providing the QoBP framework
that provides the capability to manage the quality of the business process
during different phases of the BPM life cycle. The next section presents a
summary of the contributions and implications of this study.
274 9
9.3 Contributions and Implications
This section presents the contributions of this study. These contributions
can be grouped into two categories: theoretical and practical. The theoret-
ical contributions have implications for academic and research community,
while the practical contributions have implications for practice.
9.3.1 Implications for Research
The theoretical contributions of this study are presented below.
Contribution 1 - Quality-aware BPM Life Cycle
A quality management model that is suitable for a BPM life cycle was pro-
posed in Section 2.3.4. Section 4.2 of this thesis presented how this quality
management model can be incorporated into the BPM life cycle to produce a
quality-aware BPM life cycle. In the quality-aware BPM life cycle, the qual-
ity of a business process is managed based on the four key phases of quality
definition, quality implementation, quality control, and quality improvement.
Contribution 2 - Business Process Quality Dimension
Section 4.3.2 presented the proposed business process quality dimensions in
the form of a quality model. In a quality model, the quality of a business
process is based on four distinct dimensions: quality of functions, quality of
input and output objects, quality of human resources, and quality of non-
human resources. Each dimension is then described in terms of its qual-
ity characteristics. The quality characteristics for all these four dimensions
were presented in Section 4.3.2. The proposed quality model provides a well
structured model to capture and represent quality (non-functional) charac-
teristics of a business process. The quality model is an important artifact
of the QoBP framework proposed by this study.
Contribution 3 - Quality-aware Business Process Model
This study provided the QoBP framework to create a quality-aware busi-
ness process model. Sections 4.3 and 4.4 presented the essential models of
the QoBP framework, the quality model, the softgoal model, the softgoal
correlation model, and the measurement model. The QoBP metamodel (see
9.3 275
Section 4.4.5.2) and the QoBP methodology (see Section 4.4.6) were intro-
duced to enable the creation of a quality-aware business process model. The
QoBP framework provides a systematic and novel goal-driven approach to
incorporate the quality requirements of a business process into a business
process model, producing a quality-aware business process.
Contribution 4 - Process Root Cause Analysis (PRCA) Technique
Section 4.5 presented a novel root cause analysis approach (PRCA tech-
nique) for business processes. The PRCA technique provides a systematic
and consistent approach to identify the root causes of a quality issue in an
instance of a business process. It provides the investigator the ability to
identify the sequence of all events leading to the causes of a quality issue. It
also provides the investigator the appropriate information (such as the con-
text in which the issue has occurred) that is required to conduct corrective
actions.
Contribution 5 - Research Methodological Contribution
This study demonstrated how a staged approach in defining the research
questions can be used to define and control the scope of a research. The
main research question was defined during the early stages of this research.
A comprehensive literature review was conducted to establish the context
for describing and elaborating the problem being identified. The main re-
search question that was addressed by this early investigation led to a pro-
posal for a quality-aware BPM life cycle (see Section 4.2) in which a quality
management model was incorporated into a BPM life cycle. Introduction of
the quality-aware BPM life cycle generated several research questions which
were related to different phases of the quality-aware BPM life cycle. The
scope definition was made based on the criticality of the research questions
that needed to be addressed to solve the original problem identified.
This study utilised the design science approach and action research
methodology with the aim to “deliver practical value to the subject while
at the same time contributing to theory” [31]. This research closely followed
the IS research framework [2], which is based on combining design science
(develop / build) and behaviourial science (justify/evaluate) paradigms such
276 9
as action research (see Figure 3.1). This study demonstrated how these two
powerful paradigms can be utilised to create knowledge that is not only
relevant to both practice and theory but is also rigorous.
This study is also an exemplar of providing an action research protocol
to enforce the quality and rigor of the action research. The action research
protocol provided guidelines for selecting an appropriate host organisation,
plan of engagement, guidelines for procedures related to organisation visits,
templates to use during the various activities, and the reporting format.
Contribution 6 - Contribution to IS Research
This study meets the seven guidelines for effective information systems re-
search, recommended by Hevner et al. [2]. These seven guidelines were de-
scribed in detail in Section 3.5. The business need for this research stems
from the importance of quality management of business processes. The ar-
tifacts proposed and presented in this thesis contribute to quality man-
agement of business processes during the different stages of their life cy-
cle. These artifacts were developed based on prior research in the areas of
quality management models, software engineering, goal modelling, and root
cause analysis techniques. The usability, usefulness, and scalability of the
artifacts developed in this research were evaluated by conducting action re-
search. The cumulative knowledge base built as the result of this research
has been communicated by several conference & workshop articles that have
been published or are planned to be submitted for publication.
The conformance of this work to Information Systems research guidelines
confirms that this thesis adequately meets international research standards
in this discipline.
9.3.2 Implications for practice
The purpose of this section is to outline the implications of this study for
use in practice. The practical contributions of this study are presented be-
low.
9.4 277
Contribution 1 - Quality-aware Business Processes
The adoption of the QoBP framework will assist organisations to: (1) iden-
tify their quality requirements through a systematic approach; (2) embed
these quality requirements into their business processes in a format that
can be implemented, monitored during process enactment, and improved
during process improvement.
Contribution 2 - Process Root Cause Analysis
This study provides organisations with the capability to conduct root cause
analysis on business processes. The PRCA technique enables organisations
to improve the quality of their business processes by identifying the root
causes of quality issues in instances of those processes.
Contribution 3 - Business Process Modelling Tools
This study provided an extension to the EPC metamodel (the QoBP meta-
model) that can be adopted by vendors who provide business process mod-
elling tools. These vendors can extend their modelling tools based on the
QoBP metamodel to support modelling of the quality-aware business pro-
cesses.
This study provided an automation tool referred to as the QoBP au-
tomation tool (see Appendix Appendix C.13) which proved that the QoBP
framework lends itself to an automated solution. It is envisaged that the
vendors who provide business process modelling tools can benefit from im-
plementing the QoBP framework into their toolset.
Having outlined the contributions and implications of this study, the next
section presents the limitations during the different stages of this study.
9.4 Research Limitations
The purpose of this section is to outline the limitations identified during
the different stages of this study and how these limitations were addressed.
Limitations in the Literature Review Phase
A comprehensive literature review was conducted during the early stages
278 9
of this study to establish the context for describing and elaborating the
problem identified. The main research question that was addressed by this
early investigation led to a proposal for a quality-aware BPM life cycle (see
Section 4.2) which consists of four phases: quality definition, quality imple-
mentation, quality control, and quality improvement. Introduction of the
quality-aware BPM life cycle generated several research questions which
were related to the different phases of this life cycle. Addressing all these
research questions was beyond the scope of this research. Therefore, the
research questions related to the second and third phases (quality imple-
mentation and quality control) of the quality-aware BPM life cycle were
de-scoped. The scope definition was made based on the criticality of the re-
search questions that needed to be addressed to solve the original problem
identified.
Limitation in the Design Science Phase
A limitation arising during the design science phase of this study was the de-
velopment of the artifacts to address the research questions without a proper
evaluation prior to the action research phase. As described in Section 3.2,
this research employed a multi-method research methodology which was
based on a design science approach and action research methodology. The
evaluation of these artifacts in practice was intended to occur during the
action research phase of this study. The risk with this limitation was a ma-
jor re-work (re-design) of the developed artifacts during the action research
phase when the researcher could evaluate these artifacts in practice. The
researcher mitigated the risks associated with this limitation by evaluating
the artifacts during the design phase. This pilot case (RFP process of Soft-
ware House SH) was based on a real practice drawn from the researcher’s
business experience.
Limitation in the Action Research Phase
The selection of host organisations for the action research cycles was con-
strained by budgetary and accessibility issues. As a result, all the organ-
isations selected to host action research cycles were in the finance sector
and based in Queensland, Australia. Access to additional information and
Subject Matter Experts was limited in all three cycles, due to strict privacy
9.5 279
rules & regulations that finance organisations are obliged to adhere to.
The workshops conducted during the action research cycles did not ex-
actly follow the structure (i.e. duration and number of sessions) that was
designed in the action research protocol. The researcher was obliged to be
flexible to meet workshops participants commercial priorities.
The need and appropriateness for PRCA was clearly seen during the first
and second cycles of the action research. The evaluation of the PRCA tech-
nique was not intentionally planned to be included in the initial cycles of
the action research as it was essential to ensure the maturity of the QoBP
framework. Hence the PRCA technique was only evaluated during the third
cycle of the action research which was limiting the iterative enhancement
of the PRCA technique.
9.5 Future Research
This research has provoked some questions that can be resolved during sub-
sequent research activities. This section makes some recommendations for
future research which include, but are not limited to:
• Providing supporting frameworks and artifacts for the quality control
phases of the quality-ware BPM life cycle. After conducting the third
cycle and evaluating the PRCA technique it became apparent that the
PRCA technique can be performed as a proactive approach during the
quality control phases of the quality-ware BPM life cycle. Constant mon-
itoring of the quality metrics of an enacted process during the quality
control phases can be used to proactively identify quality issues as they
occur. Further investigation and validation of the PRCA technique in a
proactive mode will be beneficial and a complement to the quality-aware
business process life cycle.
• Exploring the automation of the PRCA technique and the validation of
the automation tool in practice. One of the concerns raised during the
280 9
evaluation stage of the third action research cycle was the scalability
and accuracy of the PRCA technique for larger business processes (see
Section 8.4.6). It could be an issue where a large number of softgoals are
required to be manually traced and evaluated. The recommendation was
to automate the PRCA technique by extending the QoBP automation
tool and evaluate the tool in practice to ensure its accuracy and scala-
bility.
• Investigating in more detail the human resource dimension of the quality
model. While the quality characteristics defined for the human resource
dimension proved to be comprehensive for all the action research cycles,
the list of characteristics could be enhanced by further investigation in
the human resource field.
• Exploring the extension of the non-human resource quality dimension
to include quality characteristics related to the environmental context
effecting the enactment of business processes. In this thesis, the qual-
ity characteristics defined for the non-human resource dimension were
limited to physical assets such as computer systems, printers, etc. Fur-
ther research to explore the inclusion of the environmental context in the
non-human resource dimension could enhance the QoBP framework.
9.6 Chapter Summary
In conclusion, this thesis addressed the main research problem (How can
organisations manage the quality of business processes during the different
phases of the BPM life cycle? ) by delivering validated artifacts. The vali-
dated artifacts such as QoBP framework, QoBP metamodel, QoBP method-
ology, PRCA technique, and the QoBP automation tool provide a unique
contribution to BPM that are both rigorously defined and documented to
be of practical use in the enterprise.
References
1. Mendling, J.: Metrics for Process Models: Empirical Foundations of Verification, Error
Prediction, and Guidelines for Correctness. Springer (2008)
2. Hevner, A., March, S., Park, J., Ram, S.: Design science in information systems research.
MIS Quarterly 28 (2004) 75105
3. Susman, G., Evered, R.: An assessment of the scientific merits of action research. Infor-
mation Systems Journal 4 (1978) 582– 603
4. Weske, M.: Business Process Management: Concepts, Languages, Architectures. Springer
(2007)
5. Smith, H., Fingar, P.: Business process management: the third wave. Meghan-Kiffer Press,
Tampa, Florida (2003)
6. Group, G.: Delivering its contribution: The 2005 cio agenda. Technical Report EXP
Premier Report Nr. January2005, Gartner, Inc. Stamford, Connecticut (2005)
7. Group, G.: Growing it’s contribution: The 2006 cio agenda. Technical Report EXP Premier
Report Nr. January2006, Gartner, Inc. Stamford, Connecticut (2006)
8. Group, G.: Creating enterprise leverage: The 2007 cio agenda. Technical Report EXP
Premier Report Nr. January2007, Gartner, Inc. Stamford, Connecticut (2007)
9. Anupindi, R., Chopra, S., Deshmukh, S., Mieghem, J., Zemel, E.: Managing Business
Process Flows. Prentice Hall (1999)
10. Juran, J.M.: Managerial Breakthrough: the classic book on improving management per-
formance. MacGaw Hill (1995)
11. Li, G., Rajagopalan, S.: Process improvement, quality, and learning effects. MANAGE-
MENT SCIENCE 44 (1998) 1517–1532
12. Sinclair, D., Zairi, M.: Benchmarking best-practice performance measurement within com-
panies using total quality management. Benchmarking for Quality Management & Tech-
nology 2 (1995) 53–75
13. Sinclair, D., Zairi, M.: Performance measurement as an obstacle to tqm. The TQM
Magazine 7 (1995) 4245
14. Hammer, M., Champy, J.: Reengineering the corporation: a manifesto for business revolu-
tion. Nicholas Brealey Publ., London (1993)
15. Mendling, J., Muehlen, M., Price, A.: Standards for Workflow Definition and Execution.
In: Process Aware Information Systems: Bridging People and Software Through Process
Technology. Wiley Publishing (2005)
16. C. J. Pavlovski, J.Z.: Non-functional requirements in business process modeling. In: In
Proceedings of the Fifth on Asia-Pacific Conference on Conceptual Modelling (APCCM),
Wollongong, NSW, Australia. (2008)
282 References
17. B. Klefsjo, H. Wiklund, R.L.E.: Six sigma seen as a methodology for total quality man-
agement. Measuring Business Excellence 5 (2001) 31–35
18. Powell, T.C.: Total quality management as competitive advantage: A review and empirical
study. Strategic Management Journal 16 (1995) 15–37
19. Hammer, M.: Reengineering work: Don’t automate, obliterate. Harvard Business Review
68 (1990) 104–113
20. Davenport, T., Short, J.: The new industrial engineering: Information technology and
business process redesign. Sloan Management Review 31 (1990) 11–27
21. Harrington, H.J., K. C. Esseling and, V.N.: Business Process Improvement Workbook:
Documentation, Analysis, Design, and Management of Business Process Improvement.
McGraw-Hill (1997)
22. Sinclair, D., Zairi, M.: Effective process management through performance measurement
part i applications of total qualitybased performance measurement. Business Process
Re-engineering & Management Journal, 1 (1995) 75–88
23. Sinclair, D., Zairi, M.: Effective process management through performance measurement
part ii benchmarking total qualitybased performance measurement for best practice. Busi-
ness Process Re-engineering & Management Journal 1 (1995) 1355–2503
24. Sinclair, D., Zairi, M.: Effective process management through performance measurement
part iii an integrated model of total quality-based performance measurement. Business
Process Re-engineering & Management Journal 1 (1995) 1355–2503
25. Aalst, W., Hee, K.: Workflow Management: Models, Methods, and Systems. The MIT
Press (2002)
26. zur Muhlen, M.: Workflow-based Process Controlling. Foundation, Design and Application
of workflow-driven Process Information Systems. Logos Verlag, Berlin (2004)
27. 9126-1:2001, I.: Software engineering – product quality – part 1: Quality model (2001)
28. Juran, J.: The quality trilogy a universal approach to managing for quality. Quality
Progress 19 (1986) 19–24
29. Gable, G.G.: Consultant engagement success factors: A case study affecting client in-
volvement in, and satisfaction with, consultant engagement in computer system selection
projects, carried out for the small enterprise computerisation programme, in singapore.
University of Bradford (1991)
30. Emory, C.W.: Business research methods (3rd ed.). Homewood, Illinois: R.D. Irwin. (1985)
31. Galliers, R.: Choosing information systems research approaches. Information systems
research: issues, methods and practical guidelines (1992) 144–162
32. Andriessen, D.: Combining design-based research and action research to test management
solutions. In: Proceedings of the 7th World Congres Action Research, Groningen, The
Netherlands. (2006)
33. Webster, J., Watson, R.T.: Analyzing the past to prepare for the future: Writing a literature
review. MIS Quarterly 26 (2002)
34. Baumeister, R.F., Leary, M.R.: Writing narrative literature reviews. Review of general
psychology 1 (1997) 311–320
35. Lindsay, A., Downs, D., Lunn, K.: Business processesattempts to find a definition. Infor-
mation and Software Technology 45 (2003) 1011–1089
36. Porter, M.E.: Competitive advantage: creating and sustaining superior performance. Free
Press, New York (1985)
37. Harmon, P.: Business process change: a manager’s guide to improving, redesigning, and
automating processes. Morgan Kaufmann, Amsterdam (2003)
References 283
38. Rummler, G.A., Brache, A.P.: Improving performance. Jossey Bass Wiley, San Francisco
(1990)
39. Shin, N., Jemella, D.F.: Business process reengineering and performance improvement the
case of chase manhattan bank. Business Process Management Journal 8 (2002) 351–363
40. Taylor, F.: The Principles of Scientific Management. Harper and Brothers, New York and
London (1911)
41. J. Jeston, J.N.: Business Process Management: Practical Guidelines to Successful Imple-
mentations. Second edition edn. Butterworth-Heinemann (2006)
42. Puah, P., Tang, N.: Business process management, a consolidation of bpr and tqm. In: In
Proceedings of the 1st IEEE International Conference on Management of Innovation and
Technology, Singapore. Volume 1. (2000) 110 –115
43. Zairi, M.: Business process management: a boundaryless approach to modern competitive-
ness. Business Process Management Journal 3 (1997) 64–80
44. Curtis, B., Kellner, M.I.: Process modeling. Communications of the ACM 35 (1992) 75–90
45. Crosby, P.B.: Quality is free: The art of making quality certain. McGraw-Hill (1979)
46. Feigenbaum, A.V.: Total Quality Control. McGraw-Hill Company (1986)
47. Juran, J.M., Seder, L.A., Gryna, F.M.J.: Quality control handbook. 2nd ed edn. McGraw-
Hill (1962)
48. Moody, D., Sindre, G., Brasethvik, T., Sølvberg, A.: Evaluating the quality of process
models: Empirical testing of a quality framework. In Spaccapietra, S., March, S.T., Kam-
bayashi, Y., eds.: Conceptual Modeling - ER 2002, 21st International Conference on Con-
ceptual Modeling, Tampere, Finland, October 7-11, 2002, Proceedings. Volume 2503 of
Lecture Notes in Computer Science., Springer (2002) 380–396
49. Becker, J., Rosemann, M., von Uthmann, C.: Guidelines of business process modeling.
Business Process Management (200) 30–49
50. Recker, J.: A socio-pragmatic constructionist framework for understanding quality in pro-
cess modelling. Australasian Journal of Information Systems 14 (2007) 43–63
51. Vanderfeesten, I., Cardoso, J., Mendling, J., Reijers, H., van der Aalst, W.: Quality Metrics
for Business Process Models. In: 2007 BPM and Workflow Handbook. Workflow Manage-
ment Coalition (2007) 179–190
52. Samuel, K.M., Samuel, K.H.: Operations and Quality Management. Thomson Learning
EMEA (1999)
53. Group, W.W.: Qos for web services: Requirements and possible approaches (2003)
54. Naumann, F., Rolker, C. In: Assessment Methods for Information Quality Criteria, Cam-
bridge, MA, USA. (2000) 148–162
55. Liu, K., Zhou, S., Yang, H.: Quality metrics of object oriented design for software develop-
ment and re-development. In: Proceedings of the 1st Asian Pacific Conference on Quality
Software , Hong Kong, China. (2000) 127–135
56. Lee, Y., Strong, D., Kahn, B., Wang, R.: Aimq: A methodology for information quality
assessment. Information and Management 40 (2002) 133–146
57. Kahn, B., Strong, D., Wang, R.: Information quality benchmarks: Product and service
performance. Communications of the ACM 45 (2002) 184–192
58. Shewhart, W.A.: Economic Control of Quality of Manufactured Product. (1931)
59. Stephens, K.S.: The Handbook of Applied Acceptance Sampling: Plans, Principles, and
Procedures. American Society for Qualit (2001)
60. Deming, W.E.: Out of the crisis: For Industry, Government, Education. MIT Press (2000)
61. Shewhart, W.A., Deming, W.E.: Statistical Method from the Viewpoint of Quality Control.
Courier Dover Publications (1986)
284 References
62. Stoumbos, Z.G., Jr., M.R.R., Ryan, T., Woodall, W.H.: The state of statistical process
control as we proceed into the 21st century. Journal of the American Statistical Association
95 (2000)
63. Cheng, T.C.E., Podolsky, S., Jarvis, P.: Just-in-time Manufacturing. Springer (1996)
64. LEE, S.M., EBRAHIMPOUR, M.: Just-in-time production system: Some requirements
for implementation. International Journal of Operations and Production Management 4
(1984) 3–15
65. Sakakibara, S., Flynn, B., Schroeder, R.G.: A framework and measurement instrument for
just-in-time manufacturing. Production and Operations Management 2 (1993) 177–94
66. Sriparavastu, L., Gupta, T.: An empirical study of just-in-time and total quality manage-
ment principles implementation in manufacturing firms in the usa. International Journal
of Operations & Production Management 17 (1997) 1215–1232
67. Petersen, P.B.: Total quality management and the deming approach to quality manage-
ment. Journal of Management History 5 (1999) 468 – 488
68. Lau, R., Anderson, C.: A three-dimensional perspective of total quality management.
International Journal of Quality & Reliability Management 15 (1998) 85 – 98
69. Shenawy, E.E., Baker, T., Lemak, D.J.: A meta-analysis of the effect of tqm on competitive
advantage. International Journal of Quality & Reliability Management 24 (2007) 442 –
471
70. Wittenberg, G.: Kaizenthe many ways of getting better. Assembly Automation 14 (1994)
12 – 17
71. Imai, M.: A commonsense, low cost approach to management. McGraw Hill, New York,
USA (1997)
72. Berger, A.: Continuous improvement and kaizen: standardization and organizational de-
signs. Integrated Manufacturing Systems 8 (1997) 110–117
73. Snee, R.: Six sigma: the evolution of 100 years of business improvement methodology.
International Journal of Six Sigma and Competitive Advantage 1 (2004) 4–20
74. Antony, J.: Six sigma for service processes. Business Process Management Journal 12
(2006) 234–248
75. Jiju, A., M Kumar, C.M.: Six sigma in small- and medium-sized uk manufacturing en-
terprises: Some empirical observations. International Journal of Quality & Reliability
Management 22 (2005) 860–874
76. Arnheiter, E.D., Maleyeff, J.: The integration of lean management and six sigma. The
TQM Magazine 17 (2005) 5 – 18
77. Adams, G.: Six Sigma Deployment. Praveen Gupta and Charles Wilson (2002)
78. E. Ike Ehie, S.C.: Integrating six sigma and theory of constraints for continuous improve-
ment: a case study. Journal of Manufacturing Technology Management 16 (2005) 542–553
79. George, M.L.: Lean Six Sigma: Combining Six Sigma Quality with Lean Speed. McGraw-
Hill Professional (2002)
80. IT Governance Institute (ITGI) www.itgi.org: COBIT 4.1 - Framework, Control Objec-
tives, Management Guidelines, Maturaity Models. (2007)
81. Grigori, D., Casati, F., Dayal, U., Shan, M.C.: Improving business process quality through
exception understanding, prediction, and prevention. In Apers, P., Atzeni, P., Ceri, S.,
Paraboschi, S., Ramamohanarao, K., Snodgrass, R., eds.: VLDB 2001, Proceedings of 27th
International Conference on Very Large Data Bases, September 11-14, 2001, Roma, Italy,
Morgan Kaufmann (2001) 159–168
82. Vaishnavi, K., K. Vaishnavi Vijay and, J.W.K.: Design Science Research Methods and
Patterns: Innovating Information and Communication Technology. CRC Press (2007)
References 285
83. Mingers, J.: Combining is research methods: towards a pluralist methodology. Information
Systems Research 12 (2001) 240259
84. Mingers, J.: The paucity of multi-method research: a review of the information systems
literature. Information Systems Journal 13 (2003) 233–249
85. March, S., Smith, G.: Design and natural science research on information technology.
Decision Support Systems 15 (1995) 251–266
86. Baskerville, R., Myers, M.D.: Special issue on action research in information systems:
Making is research relevant to practiceforeword. MIS Quarterly 28 (2004) 329–335
87. Walls, J., Widmeyer, G., Sawy, O.E.: Building an information system design theory for
vigilant eis. Information Systems Research 3 (1992) 36–59
88. March, S., Smith, G.: Design and natural science research on information technology.
Decision Support Systems 15 (1995) 251–266
89. Cole, R., Purao, S., Rossi, M., Sein, M.: Being proactive: where action research meets design
research. In: In Proceedings of the Twenty-Sixth International Conference on Information
Systems. (2005)
90. Chiasson, M., Germonprez, M., Mathiassen, L.: Pluralist action research: a review of the
information systems literature. Information Systems 13 (2008) 240259
91. Davison, R., Martinsons, M., Kock, N.: Principles of canonical action research. Information
Systems Journal 14 (2004) 65–86
92. Eisenhardt, K.: Building theories from case study research. Academy of Management
Review 14 (1989) 532–550
93. Scheer, A.W., Thomas, O., Adam, O.: Process Modeling Using Event-Driven Process
Chains. In: Process Aware Information Systems: Bridging People and Software Through
Process Technology. Wiley Publishing (2005) 119–146
94. Juran, J.M., Seder, L.A., Gryna, F.M.J.: Quality control handbook. 4th ed edn. McGraw-
Hill (1988)
95. Marcellus, R.L., Dada, M.: Interactive process quality improvement. Management Science
37 (1991) 1365–1376
96. Ittner, C.D.: Exploratory evidence on the behavior of quality costs. OPERATIONS RE-
SEARCH 44 (1996) 114–130
97. Heravizadeh, M., Edmond, D.: Making workflows context-aware: A way to support
knowledge-intensive tasks. In: In Proceedings of the Fifth on Asia-Pacific Conference
on Conceptual Modelling (APCCM), Wollongong, NSW, Australia. (2008) 79–88
98. Rosemann, M., Recker, J., Flender, C., Ansell, P.: Understanding context-awareness in
business process design. In: Proceedings 17th Australasian Conference on Information
Systems, Adelaide, Australia. (2006)
99. Aburub, F., Odeh, M., Beeson, I.: Modelling non-functional requirements of business
processes. Information and Software Technology 49 (2007) 1162–1171
100. Osterweil, L.: Software processes are software too. In: Proceedings of the 9th international
conference on Software Engineering (ICSE 87), Los Alamitos, CA, USA, IEEE Computer
Society Press (1987) 2–13
101. Bernstein, P.: Middleware: A model for distributed systems services. Communications of
the ACM 39 (1996) 8698
102. Casati, F., Jin, S.I.L.J., Shan, V.K.M.C.: Adaptive and dynamic service composition in
eflow. In: Proceedings of the Int. Conference on Advanced Information Systems Engineering
(CAiSE), , Stockholm, Sweden, Springer Verlag (200)
103. Jennings, N., Norman, T., Faratin, P., OBrien, P., B., Odgers: Autonomous agents for
business process management. Journal of Applied Artificial Intelligence 14 (2000) 145189
286 References
104. Schuster, H., Georgakopoulos, D., Baker, A.C.D.: Modeling and composing service-based
and reference process-based multi-enterprise processes. In: Proc. of the Int. Conference on
Advanced Information Systems Engineering (CAiSE), Stockholm, Sweden, Springer Verlag
(2000)
105. 9126-2:2003, I.: Software engineering – product quality – part 2: External metrics (2003)
106. 9126-3:2003, I.T.: Software engineering – product quality – part 3: Internal metrics (2003)
107. 9126-4:2004, I.T.: Software engineering – product quality – part 4: Quality in use metrics
(2003)
108. Dumas, M., O’Sullivan, J., Heravizadeh, M., Edmond, D., t. Hofstede, A.: Towards a
semantic framework for service description. In: Proceedings of 9th IFIP 2.6 Working
Conference on Database Semantics (DS-9), Hong Kong, China. (2001)
109. bject Management Group: Uml profile for modeling qos and ft characteristics and mecha-
nisms specification v1.0 (2006)
110. O’Sullivan, J., Edmond, D., ter Hofstede, A.: What’s in a service? towards accurate de-
scription of non-functional service properties. Distributed and Parallel Databases 12 (2002)
117–133
111. 13236:1998, I.: Information technology – quality of service: Framework (1998)
112. Liangzhao, Z., Benatallah, B., Dumas, M., Kalagnanam, J., Sheng, Q.Z.: Quality-driven
web services composition. In: In Proceedings of 12th International Conference on the World
Wide Web (WWW), Budapest, Hungary. (2003) 411–421
113. Yu-jie, M., Jian, C., Shen-sheng, Z., Jian-hong, Z.: Interactive web service choice-making
based on extended qos model. In: In Proceedings of the Fifth International Conference on
Computer and Information Technology. (2005) 1130 – 1134
114. Tondello, G., Siqueira, F.: The qos-mo ontology for semantic qos modeling. In: In Pro-
ceedings of SAC 2008. (2008) 2336–2340
115. Cykana, P., Paul, A., Stern, M.: Dod guidelines on data quality management. In: In
Proceedings of the Conference on Information Quality, Cambridge, MA. (1996) 154171
116. Kovac, R., Lee, Y., Pipino, L.: Total data quality management: the case of iri. In: In
Proceedings of the Conference on Information Quality, Cambridge, MA. (1997) 6379
117. Wang, R., Strong, D.: Beyond accuracy: What data quality means to data consumers.
Management Information System 12 (1996) 533
118. McClelland, D.: Testing for competence rather than for intelligence. American Psychologist
28 (1973) 1–14
119. Neves, J., Caetano, A., Vasconcelos, A., Tribolet, J.: Integrating knowledge into business
processes. In: Proceedings of ICEIS 2001. (2001)
120. Caetano, A., Pombinho, J., Tribolet, J.: Representing organizational competencies. In:
SAC ’07: Proceedings of the 2007 ACM symposium on Applied computing, New York,
NY, USA, ACM (2007) 1257–1262
121. Spencer, L.M., Jr., Spencer, S.M.: Competence at Work: models for superior performance.
John Wiley and Sons, Inc., first ed. (1993)
122. Lang, A., Pigneur, Y.: igital trade of human competencies. In: Proceedings of HICSS 32,
IEEE. (1999)
123. Sandberg, J.: Understanding human competence at work: An interpretative approach. The
Academy of Management Journal 43 (2000) 9–25
124. (Harzallah, M., Lecrere, M.)
125. van der Aalst, W.: Formalization and verification of event-driven process chains. Informa-
tion and Software Technology 41 (1999) 639650
References 287
126. Heravizadeh, M., Mendling, J., Rosemann, M.: Root cause analysis in business processes.
Technical report, Qut eprint, Queensland University of Technology (2008)
127. Park, R.E., Goethert, W.B., Florac, W.A.: Goal-driven software measurement a guide-
book. Handbook CMU/SEI-96-HB-002, Software Engineering Institute, Carnegie Mellon
University, Hanscom, MA (1996)
128. Jureta, I.J., Faulkner, S., Schobbens, P.Y.: A more expressive softgoal conceptualization
for quality requirements analysis. In: Proceedings of the 25th International Conference on
Conceptual Modeling, Tucson, Arizona. (2006) 281–295
129. Nuseibeh, B.A., Easterbrook, S.M.: Requirements engineering: A roadmap. In: proceedings
of the 22nd International Conference on Software Engineering, ICSE’00. (2000)
130. Cysneiros, L., Yu, E.: Perspectives on Software Requirements. In: Non-Functional Re-
quirements Elicitation. Kluwer Academic Publishers (2004) 115–138
131. Abran, A., Al-Qutaish, A., Desharnais, J., Habra, N.: An information model for software
quality measurement with iso standards. In: Proceedings of the SWDC-REK International
Conference on Software Development, Rekjavick, Iceland. (2005)
132. Stevens, S.: On the theory of scale types and measurement. Science 103 (1946) 677–680
133. Dardenne, A., Lamsweerde, A.V., Fickas, S.: Goal-directed requirements acquisition. In:
Science of Computer Programming. (1993) 3–50
134. Chung, L., Nixon, B.A.: Dealing with non-functional requirements: Three experimental
studies of a process-oriented approach. In: International Conference on Software Engineer-
ing. (1995) 25–37
135. Anton, A.: Goal-based requirements analysis. In: In Proceedings of ICRE ’96, IEEE,
Colorado Springs, Colorado USA. (1996) 136–144
136. Castro, J., adn J. Mylopoulos, M.K.: Towards requirements-driven information systems
engineering: the tropos project. Info. Sys. 27 (2002) 365389
137. Kavakli, E., Loucopoulos, P.: Information Modeling Methods and Methodologies (Adv.
topics of Database Research). In: oal Driven Requirements Engineering: Analysis and
Critique of Current Methods. IDEA Group (2004) 102 – 124
138. Grau, G., Franch, X., Maiden, N.A.M.: Prim: An i*-based process reengineering method
for information systems specification. Information and Software Technology 50 (2008)
76–100
139. Loucopoulos, P., Karakostas, V.: System Requirements Engineering. McGraw Hill, London
(1995)
140. C, R.: Reasoning with goals to engineer requirements. In: Fifth International Conference
on Enterprise Information Systems, Angers, France. (2003) 11–19
141. Kavakli, E.: Goal oriented requirements engineering: A unifying framework. Requirements
Engineering Journal, Springer-Verlag London 6 (2002) 237–251
142. Yu, E., Bois, P.D., Dubois, E., Mylopoulos, J.: From organization models to system require-
ments – a “cooperating agents” approach. In: Proceedings of 3rd International Conference
on Cooperative Information Systems – CoopIS-95, Vienna (Austria. (1995) 194–204
143. Bresciani, P., Perini, A., Giorgini, P., Giunchiglia, F., Mylopoulos, J.: Tropos: an agent-
oriented software development methodology. Journal of Autonomous Agents and Multi-
Agent Systems, Kluwer Academic Publishers 8 (2004) 203236
144. Kavakli, E., Loucopoulos, P.: Goal driven requirements engineering: Evaluation of cur-
rent methods. In: In Proceedings of the 8th CAiSE/IFIP8.1 International Workshop on
Evaluation of Modeling Methods in Systems Analysis and Design (EMMSAD ’03), Velden,
Austria. (2003)
288 References
145. Antn, A.I.: Goal-based requirements analysis. In: Second International Conference on
Requirements Engineering ( ICRE 96) , IEEE, Press (1996) 136–144
146. Anton, A., Potts, C.: The use of goals to surface requirements for evolving systems. In:
Proceedings of International Conference on Software Engineering (ICSE 98), Kyoto, Japan.
(1998) 157–166
147. Basili, V.R., Caldiera, G., Rombach, H.D.: Goal question metric approach. Encyclopedia
of Software Engineering 1 (1994) 528–532
148. Solingen, R.V., Berghout, E.: Measurement in industrial software engineering: Industrial
experiences with and additions to the goal/question/metric method (gqm). In: Proceed-
ings of the Seventh International Software Metrics Symposium (METRICS 2001), London,
England. (2001) 246–258
149. Berander, P., Jonsson, P.: A goal question metric based approach for efficient measurement
framework definition. In: International Symposium on Empirical Software Engineering
(ISESE 2006), Rio de Janeiro, Brazil. (2006) 316–325
150. Cleland-Huangs, J., Settimi, R., BenKhadra, O., Berezhanskaya, E., Christina, S.: Goal-
centric traceability for managing non-functional requirements. In: Proceedings of the 27th
international conference on Software engineering, St. Louis, MO, USA. (2005) 362–371
151. Subramanian, N., Chung, L.: Metrics for software adaptability. Applied Technology Divi-
sion, Anritsu Company (1999)
152. Letier, E., van Lamsweerde, A.: Reasoning about partial goal satisfaction for requirements
and design engineering. SIGSOFT Softw. Eng. Notes 29 (2004) 53–62
153. Rolland, C., Prakash, N., Benjamen, A.: A multi-model view of process modelling. Requir.
Eng. 4 (1999) 169–187
154. Kavakli, E., Loucopoulos, P.: Experiences with goal-oriented modelling of organisational
change. IEEE Transactions on Systems, Man and Cybernetics - Part C 36 (2006) 221–235
155. Kueng, P., Kawalek, P.: Goal-based business process models: creation and evaluation.
Business Process Management Journal 3 (1997) 17–38
156. Neiger, D., Churilov, L., Flitman, A.: Value-Focused Business Process Engineering : a
Systems Approach with Applications to Human Resource Management. Springer (2009)
157. Soffer, P., Wand, Y.: Goal-driven analysis of process model validity. In Persson, A.,
Stirna, J., eds.: Advanced Information Systems Engineering, 16th International Conference,
CAiSE 2004, Riga, Latvia, June 7-11, 2004, Proceedings. Volume 3084 of Lecture Notes in
Computer Science., Springer (2004) 521–535
158. Kavakli, V., Loucopoulos, P.: Goal-driven business process analysis - application in elec-
tricity deregulation. Information Systems 24 (1999) 187–207
159. Soffer, P., Wand, Y., Kaner, M.: Semantic analysis of flow patterns in business process
modeling. In Alonso, G., Dadam, P., Rosemann, M., eds.: Business Process Management,
5th International Conference, BPM 2007, Brisbane, Australia, September 24-28, 2007,
Proceedings. Volume 4714 of Lecture Notes in Computer Science., Springer (2007) 400–
407
160. Donzelli, P.: A goal-driven and agent-based requirements engineering framework. Require-
ments Engineering 9 (2004) 16–39
161. Lamsweerde, A.V.: Goal-oriented requirement engineering: a guided tour. In: Proceedings
of the RE’01 Int. Joint Conference on Requirement Engineering. (2001) 249–63
162. Mylopoulos, J., Chung, L., Liao, S., Wang, H., Yu, E.: Exploring alternatives during
requirements analysis. IEEE Software 18 (2001) 92–96
163. Levy, A.: Basic Set Theory. Courier Dover Publications (2002)
References 289
164. Alcantud, J.: Weak utilities from acyclicity. Theory and Decision 47 (1999) 185–196
165. Davies, I., Green, P., Rosemann, M., Indulska, M., Gallo, S.: How do practitioners use
conceptual modeling in practice? Data & Knowledge Engineering 58 (2006) 358–380
166. Becker, J., Kugeler, M., Rosemann, M.: Process Management: A Guide for the Design of
Business Processes. Springer-Verlag (2003)
167. Rosemann, M.: Process Management. A Guide for the Design of Business Processes.
Springer-Verlag (2003)
168. Chen, P.P.S.: The entity-relationship model: Toward a unified view of data. ACM Trans-
actions on Database Systems 1 (1976) 9–36
169. Brodie, M., Mylopoulos, J., Schmidt, J.: On Conceptual Modelling: Perspectives from
Artificial Intelligence, Databases and Programming Languages. Springer Verlag (1984)
170. Rosa, M.L., Dumas, M., ter Hofstede, A., Mendling, J., Gottschalk, F.: Beyond control-
flow: Extending business process configuration to roles and objects. In: In Proceedings
of the 27th International Conference on Conceptual Modeling (ER 08), Barcelona, Spain.
Volume 5231., Springer-Verlag (2008) 199 – 215
171. Mendling, J., Aalst, W.: Formalization and Verification of EPCs with OR-Joins Based on
State and Context. In Krogstie, J., Opdahl, A., Sindre, G., eds.: Proceedings of the 19th
Conference on Advanced Information Systems Engineering (CAiSE 2007). Volume 4495 of
Lecture Notes in Computer Science., Trondheim, Norway, Springer-Verlag (2007) 439–453
172. Rosemann, M.: Potential pitfalls of process modeling: part a. Business Process Management
Journal 12 (2006) 249–254
173. Muehlen, M., Rosemann, M.: Integrating risks in business process models. In: Proceed-
ings of the 2005 Australasian Conference on Information Systems (ACIS 2005), Sydney,
Australia (2005)
174. Wilson, P., Dell, L., Anderson, G.: Root Cause Analysis: A Tool for Total Quality Man-
agement. ASQ Quality Press (1993)
175. Andersen, B., Fagerhaug, T.: Root Cause Analysis: Simplified Tools and Techniques. ASQ
Quality Press (2006)
176. Ishikawa, K., et al.: What is Total Quality Control?: The Japanese Way. Prentice-Hall
Englewood Cliffs, NJ (1985)
177. WG, J.: Mort, safety assurances systems (1980)
178. Talty, J.T.: Industrial Hygiene / Industrial Hygiene Engineering - Recognition, Measure-
ment, Evaluation and Control. William Andrew Inc. (1988)
179. Benner, L.J.: Accident Investigations: Multilinear Events Sequencing Methods. Journal of
Safety Research 7 (1975) 67–73
180. Johnson, C.W.: Failure in Safety-Critical Systems: A Handbook of Accident and Incident
Reporting. University of Glasgow Press, Glasgow, Scotland (2003)
181. Murayama, Y., Yamazaki, M., Endo: A pilot study on marine incidents. The journal of
Japan institute of navigation (1998) 257–264
182. D. Coghlan, T.B.: Doing Action Research in Your Own Organization. SAGE (2006)
183. Hartwick, J., Barki, H.: Communication as a dimension of user participation. IEEE
transactions on professional communication 44 (2001) 21–36
184. Walz, D., Elam, J., Curtis, B.: Inside a software design team: knowledge acquisition,
sharing, and integration. Communications of ACM 36 (1993) 63–77
185. Byrd, T., Cossick, K., Zmud, R.: A synthesis of research on requirements analysis and
knowledge acquisition techniques. MIS Quarterly 16 (1992) 117–138
186. Hossenlopp, R.: Unearthing Business Requirements: Elicitation Tools and Techniques.
Management Concepts (2007)
Appendix A.1 - Literature Review on Business
Process Modelling Notations
The purpose of this appendix is to present several business process modellingnotations such as Petri nets, Coloured Petri nets, EPCs, and BPMN.
1 Petri nets
Petri nets originates from the early work by Carl Adam Petri [1]. It is awell known formal notation that can be used for the specification of businessprocesses. Petri nets have been used to model and analyse different processeswith applications ranging from protocols, hardware, and embedded systemsto flexible manufacturing systems, user interaction, and business processes[2]. A large body of analysis techniques exist to determine various propertiesof Petri nets and its subclasses [3, 4, 5]. Petri nets is a formal language whichmeans the semantics of the classical Petri net have been defined formally.
Place
Output / Input Arc
Transition
Token
place 1 place 2transition 1
input output
Figure 1: Petri nets segment
Petri nets has a graphical representation that is easy to learn. Petri nets
1
have been used to model dynamic systems with a static structure. Petri netsconsists of places, transitions, directed arcs connecting places and transitionsand tokens. A place is a passive component and represents the state or acondition. A transition typically represents an action, event, operation ortransformation and is led by an output arc and trailed by an input arc. Atoken is typically a physical or information object which is a marking thatdenote the current state (in figure 1 the a token is marked in place 1 ). Afiring of a transition removes a token from its input place and places a tokenin its output place. In graphical representations, places are represented bycircles (place 1 and place 2 in figure 1), transitions by rectangles (transition1 in figure 1), and arcs by directed arrows indicating the flow (input andoutput in figure 1). The direction of an arrow indicates whether a place is aninput place of a transition or an output place of a transition. Petri net is adirected bipartite graph, meaning that arcs never connect two places or twotransitions. A Petri net together with its marking called a system. A Petrinet usually represents a business process model, while its transitions repre-sent activity models. Therefore firing of token represents an activity instance.
The classical Petri net while allows for the modeling of states, events,conditions, synchronisation, parallelism, choice, and iteration [6], it has lim-itation to model time and the data.
2 Coloured Petri nets
Coloured Petri nets is a discrete-event modelling language which is a combi-nation of classical Petri nets and the functional programming language CPNML [7]. CPN have been used as a modelling language in different applicationdomains where concurrency and communications are key characteristics suchas business processes and workflows. Unlike classical Petri nets, CPN includea time concept that provides capability to capture the time taken to executeactivities in the system. Therefore CPN can be used for simulation-basedperformance analysis, investigating performance measures such as delays,throughput, and queue lengths in the system [8]. CPN models are formal,which means that the syntax and semantics of the CPN modelling languagehas formally defined. This means that CPN is a useful tool that can be usedto verify system properties [7].
2
Place
Output / Input Arc
Transition
Token
place 1 place 2transition 1
[d1, c1][d2, c2]
If d = 0
(d,c) (d,c)
Figure 2: Coloured Petri nets (CPN) segment
In contrast to classical Petri Nets, Coloured Petri nets (CPN) tokens andplaces are colored or typed [9]. The type of a place is shown below it (‘[d1,c1]’ in figure 2). A transition may have a guard which places conditions onthe tokens that can fire the transition. Guards are shown above the transition(‘if d = 0’ in figure 2). In CPN, the behaviour of transitions is determinedby the token in the input places, guards attached to transitions and arc ex-pressions (‘(d,c)’ in figures 2). The arc expressions describe how the stateof a CPN changes when the transitions occur. When a transaction fires, thearch expression determines the tokens with appropriate values to be put onthe output places of the transition.
The expressive power and data handling capability of the CPN, make ita suitable notation to represent business process models [10].
3 Event-driven Process Chains
The Event-driven Process Chain (EPC) is a business process modeling lan-guage for the representation of temporal and logical dependencies of activities
3
in a business process [11]. EPC is an outcome of a collaborative project be-tween SAP AG1 [11] and the Institute of Information Systems (IWi) of theUniversity of Saarland, Germany. The purpose of the project was to definea suitable business process modeling language to document the processes ofthe SAP R/3 enterprise resource planning system. EPC is also utilised inthe ARchitecture of Integrated Information Systems (ARIS) framework [12]as the central method for the conceptual integration of the functional, or-ganisational, data, and output perspective in information systems design.
Event 1
Function 1
XOR
Event 3Event 4
Figure 3: An EPC Segment
EPC is not a formal notation. The main building blocks of EPC areevents, functions, connectors and control flow archs, as shown in figure 3.Functions capture activities of a process, while events describe pre-conditionsand post-conditions of functions (events trigger functions). Connector are
4
used to model the process logic. There are three kinds of connector types in-cluding AND, OR, and XOR. Connectors have either multiple incoming andone outgoing arc (join connectors) or one incoming and multiple outgoing arcs(split connectors). Control flow arcs are used to link these elements. Seman-tically, the AND-split activates all subsequent branches in concurrency. TheXOR-split represents a choice between one of several alternative branches.The OR-split triggers one, two or up to all of multiple branches based onconditions. In both cases of the XOR and OR-split, the activation condi-tions are given in events subsequent to the connector. Accordingly, splitsfrom an event to multiple functions are forbidden with XOR and OR asthe activation conditions do not become clear in the model. The AND-joinwaits for all incoming branches to complete, then it propagates control tothe subsequent EPC element. The XOR-join merges alternative branches.The OR-join synchronizes all active incoming branches.
Certain rules must be followed at the design time to avoid or reduceundesirable behavior like deadlocks. The rules summarised by [13] include:
1. Functions, events, and connectors are three main building blocks of anEPC.
2. An event should be represented by a hexagon and n appropriate nameshould be selected for an event that reflects its characteristic.
3. A function should be represented by a rectangle and an appropriatename should be selected for a function that reflects the time-consumingperspective of the accomplished task.
4. A connector should be represented by a circle. Within the circle, thetype of connector is defined through the corresponding symbol. Theconnector can be split into an upper and lower part, reflecting differ-ences between incoming and outgoing connection rules.
5. An EPC should start and end with at least one event.
6. An EPC should contain at least one function.
7. An EPC is allowed to be composed of several EPCs.
8. Archs should always connect two elements corresponding to the se-quence of activation.
5
9. An event cannot be the predecessor or the successor of another event.
10. A function cannot be the predecessor or the successor of another func-tion.
11. Each event and each function have only one incoming and/or one out-going arch.Elem ent D escription N otation Function The basic bu ild ing b locks are functions. A function corresponds to an activity (ta sk, p ro cess step) w h ich needs to be executed . Events Even ts describe the situatio n before and/or after a fun ction is executed. Functio ns are linked by events. An event m ay corresp on d to the post-cond ition of one function and act as a p recondition of another functio n. Logical connectors Conn ectors can be used to co nn ect activities and events. Th is w ay the flo w of co ntro l is specified . There are three types of co nnecto rs: ∧ , XO R (exclu sive or) and ∨
X O R V
V D ata flow connector D ata flow connectors are tem po ral-logical relationsh ip betw een functio ns and events. In form ation/M aterial In form ation , m ateria l, or re so urce ob jects in the real w orld w hich can be inpu t d ata fo r a function , o r o utput data produces by a fun ction . O rgan isation un it Specifies the organ isation un it in w ith in the en terprise responsib le for the function . Person Person w ith in an organ isation un it responsib le for th e function . Com plex function Rep re sents that a function h as a sub-process. Figure 4: Building Blocks of EPC
The extended EPC (eEPC) introduced further elements such as processparticipants or data and information systems. Figure 4 shows all the buildingblocks of an eEPC.
6
4 Business Process Modeling Notation (BPMN)
The first Business Process Modeling Notation (BPMN) specification releasein May 2004 by the Business Process Management Initiative (BPMI.org).BPMN provides a standardized, graphical language for the visualisation ofbusiness processes. A business process model produced using BPMN, so-called Business Process Diagram (BPD), consists of four basic categoriesof elements: flow objects, connecting objects, swimlanes, and artifacts [14].Figure 5 notation of the main BPMN syntax elements. Events, activities, andgateways are the three flow Objects which define the behavior of a BusinessProcess. The three connecting objects are sequence flow, message flow andassociation. Pools and lanes are two ways of grouping the primary modelingelements through “Swimlanes”. The three standard artifacts that are usedto provide additional information about the Process are data object, groupand annotation.
The main building blocks of BPMN are activities and actors carryingout those activities. The actors are represented by pools that can be furtherdivided into sub-actors by lanes. The sequence of activities inside a pool isrepresented by sequence flow. Interactions between pools is represented bymessages flows. Tokens are used to present the progress of the sequence flow.Conditions are used to indicate the decision points and either attached to theflow or different kind of gateways. Gateways allow splitting and joining ofprocesses. The gateways have three types: inclusive (OR), exclusive (XOR),complex or parallel (AND). In exclusive gateways, the sequence flow can takeonly one of the outgoing paths. In inclusive gateways, all of the combinationsof the independent paths can be taken. Parallel gateways define multiplepaths that are executed concurrently .
7
E lem ent D escription N otation Sequence F low A Sequence F low is u sed to sh ow the ord er th at activities w ill be perfo rm ed in a Process. M essage Flow A M essage Flow is u sed to show the flow of m essages b etw e en tw o partic ipants that are prepared to send an d receive them . Asso ciation An Association is used to asso ciate in fo rm ation w ith Flow O bje cts. Text and graph ical non -Flow O bjects can be associated w ith Flow O bjects. A n arrow head on th e Asso ciation ind icates a d irection o f flo w (e.g ., data), w hen appro pria te . Poo l A Poo l represents a Participan t in a Process a lso acts as a “sw im lane” and a graph ical conta in er for partition ing a set of activities from other Poo ls, usually in the context o f B2B situations. N
ame Lane A Lane is a sub-p artit ion w ith in a Poo l and w ill extend the entire length o f the Poo l, e ither vertica lly or horizonta lly . Lanes are used to organ ize and catego rize activities.
Nam
e
Nam
eN
am
e D ata O bject D ata O bjects are co n sidered Artifacts because they do not have an y d irect effect on the Sequence F low or M essage F low of the Pro cess, but they do provid e in form ation about w hat activities requ ire to be perform ed and/o r w h at they produce. Group A group ing o f activities that are w ith in the sam e category. Text Annotatio n Text Annotations are a m echan ism for a m o deler to provide add ition al in form ation for the reader o f a BPM N D iagram . D es c ript iv e tes t here Task A Task is an atom ic activ ity that is included w ith in a Process. Event An event is so m ething that “happens” du ring the course o f a business process. There are three types o f Events, based on w h en they affect th e flow : Start, In term ediate, and End . Gatew ay A Gatew ay is used to co ntro l the d ivergen ce and convergence o f m ultip le Sequence Flo w . Th us, it w ill determ ine branch ing, fork ing, m ergin g, and jo in ing o f paths.
Figure 5: BPD Element Set
8
Appendix A.2 - Literature Review on Root
Cause Analysis Techniques
The purpose of this appendix is to present an overview of the literaturereview conducted to gain knowledge on root cause analysis techniques andframeworks in other disciplines.
5 Events and Causal Factors Chart
The Events and Causal Factors Chart (ECFC) [15] is a root cause anal-ysis technique commonly used to investigate the root cause of an incidentby providing a graphical representation of the sequence of events leading toa failure. The purpose of this technique is to identify and document thesequence of events from the beginning to the end of an incident. This tech-nique does also provide the ability to identify the factors, conditions, failedbarriers, and energy flows contributing to an incident.
Event 1 Event 2 Event 3Primary Events
SequenceAccident
Secondary Events Sequence
Secondary Event 1
Secondary Event 2
Condition 2Condition 1
Figure 6: A sample Events and Causal Factors Chart
As it is shown in figure 6 in an ECFC, events are represented in rectanglesand conditions in ovals. Event are connected by solid arrows. Conditions areconnected to each others and to events by dashed arrows. In an ECFC theprimary sequence of the events are presented in a horizontal line in whichevents are connected by bold printed arrows. The secondary event sequence
9
is then presented at different levels above or below the primary sequence.The events in a sequence are arranged in chronological order.
ECFC technique is mostly used as a root cause analysis technique inthe incident analysis and occupational health and safety field. The primarypurpose of incident investigation is to determine what happened and why ithappened.
It has been proven that using a single RCA technique is not sufficient toachieve the root cause analysis in occupation health and safety [16], thereforea combination of techniques need to be used to determine what happenedand why it happened. One of the known limitations of the ECFC [17] is thelack of time scale associated with the chart which makes the investigationprocess difficult.
6 Multilinear Event Sequencing
Multilinear Event Sequencing (MES) [18] is a root cause analysis techniquescommonly used to investigate the root cause of an accident by providing agraphical representation of the actors, actions and events in an incident. AMES diagram represents an accident being investigated as a sequence of con-nected events.
As shown in figure 7 Events in a MES diagram events are representedin rectangular event blocks. Each event block containing the description ofthe action, the actor (the person or the object that performed the action)and the time of the event. Event blocks are connected via causations beingrepresented as arrows. MES diagrams have two axes, the horizontal axis thatrepresents time and the vertical axis that lists actors involved in the accident.Conditions are represented in ovals and are usually linked to event blocks viaarrows.
MES technique is mostly used as a root cause analysis technique in the
10
Action: Action 1
Actor: Actor A
Time: 9:15 AM
Actor A Accident
Condition 1
Actor B
Action: Action 3
Actor: Actor A
Time: 11:30 AM
Action: Action 2
Actor: Actor B
Time: 10:15 AM
time11:3010:159:15
Figure 7: A sample Multilinear Event Sequencing
accident analysis and occupational health and safety field. The primary pur-pose of incident investigation is to determine the sequence of events, actorscontributing to the events as well as the condition affecting the events. Theincident investigators using this technique usually start their investigationprocess by identifying the beginning and the end of an accident. Then theyconstruct the event blocks by identifying the actors associated to each event,action taken during the event and the time that the event has occurred. Thenext step is to then map the event block onto two axes, the horizontal axisthat represents time and the vertical vertical axis that lists actors involved inthe accident. Finally, they identify conditions that make the events to occur.
One of the limitations of the MES approach reported in the field is thecomplexity in developing and analysing the chart [19]. Another limitationargued by [18] is the difficulty of validating the conditions after the accidenthas occurred.
11
7 Sequentially Timed Events Plotting Proce-
dure
Sequentially Timed Events Plotting Procedure (STEP) [20] is another se-quencing root cause analysis technique used for incident investigation. TheSTEP technique is very similar to the MES (section 6) technique in the waythat it depicts each actors actions traced from the start of the incident to theend and events are represented based on the time-line they occurred. Theprocedure starts with populating the STEP cards which are the basis of keyevents of an incident. The event cards will then be used to model the eventblocks similar to the MES (section 6) technique. A typical STEP card storesinformation such as actor, action, the time of the event (beginning, end andduration), event location and description.
Start State End StateActor Events
Actor A
Actor B
Actor C
Actor D
Time
Figure 8: A sample Sequentially Timed Events Plotting Procedure
As shown in figure 8 unlike MES (section 6), being in flow chart format,STEP follows a tabular format. First column in the matrix represents thebeginning of the event while the last column represents the end of the acci-dent sequence. The actors are represented on the vertical axis. STEP doesnot show conditions in the tabular representation of event sequences.
One of the main problems with STEP, reported by [21], is the risks as-sociated to unconnected events after the causal analysis. The unconnected
12
events can cause unnecessary confusion to the investigation process.
8 Fault Tree Analysis
Fault Tree Analysis [22] is a deductive methodology that involves reasoningfrom the general to the specific. This techniques is used to determine thepotential causes of incidents. The potential causes are identified by breakingdown the top event (incident) which is the root of the fault tree to a seriesof contributory events. Figure 9 depicts a simple fault tree diagram. Eventscould be one of the three types: base, immediate or undeveloped. Basedevents are used to represent the underlying failures that lead to an accident.Logic gates (and & or) are used to represent the ways in which events arecombined.
One of the main criticism of the fault tree notation by [17], is its failure todistinguish between contextual and contributory factors and the root causesof an incident.
9 Barrier Analysis
Barrier Analysis [23] is a technique which is used for incident analysis. Itprovides a structured way to identify the events related to a failure. Threedifferent common barriers are people, process and technology. Barrier analy-sis is based on the fact that a failure occurs because barriers or controls wereunused or inadequate. Figure 10 shows the idea behind the Barrier Analysisthat barriers need to be put in between the source of the problem and targetto prevent an incident from occurring.
The Barrier Analysis is an informal and unstructured technique. Thebarriers are usually identified by an analyst through asking a set of ques-tions during the incident investigation. Barriers can usually fail for varietyof reasons such as being impossible to provide adequate barrier, or it may be
13
Top Event
And
Undeveloped Event
Immediate Event
Immediate Event
And
Or
Based Event
Undeveloped Event
Immediate Event
Or
Based Event
Based Event
Figure 9: A sample Fault Tree Analysis
14
Source of the problem Barriers Target
Figure 10: A sample Barrier Analysis
uneconomic to develop a barrier [17].
10 Change Analysis
Change Analysis is another technique used in root cause analysis of inci-dents. It provides a structured way to identify the differences between whatwas expected to occur and what actually did occur during the incident. TheChange Analysis process proposed by [24] starts with first examining the in-cident situation. The next step is to then consider comparable incident-freesituations and compare the two situations. All the differences between thetwo situations need to be documented for further analysis. The next stepinvolves the analysis of the differences and their effect on the incident andintegrating the differences into incident causal factors. The identified differ-ences provide the analyst the basis to assess the causes of the incident.
It has been argued that Change Analysis is just a complementary tech-nique to root cause analysis and has not been designed for this purpose [17].
15
11 Five Why’s
Five Why’s is an unstructured root cause analysis which is based on asking,five times, why a failure has occurred.
Five Why’s has been used as a root cause analysis techniques in earlydays of Total Quality Management (TQM) in manufacturing industries. To-tal Quality Management (TQM) provides a framework for continues improve-ment in an organisation [25]. TQM’s primary focus is on the total satisfactionof both the internal and external customers. TQM is about the prevention ofdefects and the increase in the quality of design [26]. The TQM philosophy isbased on improving quality which leads to improved productivity (decreasecost because of less rework, fewer mistake, fewer delays and better use ofmachines and materials).
12 Fish-Bone Diagram
Fish-bone diagram is a root cause analysis approach which was developed byProfessor Kaoru Ishikawa of Tokyo University in Japan. Fish-bone diagramhas also been referred to Cause & Effect or Ishikawa diagram across litera-ture. This approach is based on identifying the inputs or potential causes toa single output or effect. Figure 11 shows a sample of Fish-Bone diagram.
Fish-bone diagram has been widely used in manufacturing industry asan effective root cause analysis technique in quality management approachessuch as Total Quality Management (TQM) [25], Kaizen [27] and Six Sigma[28].
16
Problem
Category 1 Category 2 Category 3
Category 4 Category 5 Category 6
Cause 1
Cause 2
Figure 11: A sample Fish-bone Diagram)
13 Physics (Engineering) of Failure based Method-
ology (PEFM)
Physics (Engineering) of Failure based Methodology (PEFM) is a methodol-ogy based on combining the principles of physics and engineering to developand implement products that are cost effective and reliable [29]. The PEFMmethodology provides a framework to assess the root cause and effect of thepossible defect detection and prevention options.
Physics of failure approaches have been used widely by the electronic re-liability community. These approaches typically involve the use of root causefailure mechanisms to develop models to improve time to market, lower de-velopment and build costs and higher reliability [29, 30]. The main focus ofphysics-of-failure approach is the identification of the root cause of a failureto enhance the reliability of electronic systems [31].
In summary, most of failure-based root cause analysis techniques are usedin a reactive mode, i.e. to discover the reason for problems that have alreadyoccurred.
17
References
[1] Petri, C.: Fundamentals of a Theory of Asynchronous Information Flow.In: 1962 IFIP Congress, Amsterdam, North-Holland (1962) 386–390
[2] van der Aalst, W.: A class of petri net for modeling and analyzingbusiness processes. Computing science reports, University of Technology,Eindhoven (1995)
[3] Murata, T.: Petri nets: Properties, analysis and applications. In: InProceedings of the IEEE. Volume 77. (1989) 541–580
[4] Peterson, J.: Petri net theory and the modeling of systems. Prentice-Hall, Englewood Cliffs, USA (1981)
[5] Desel, J., Esparza, J.: Free choice petri nets. Cambridge Tracts inTheoretical Computer Science, Cambridge University Press, Cambridge,United Kingdom 40 (1995)
[6] van der Aalst, W.: The application of petri nets to workflow manage-ment. The Journal of Circuits, Systems and Computers 8 (1998) 21–66
[7] Jensen, K., Kristensen, L., Wells, L.: Coloured petri nets and cpntools for modelling and validation of concurrent systems. InternationalJournal on Software Tools for Technology Transfer 9 (2007) 213–254
[8] Kristensen, L., Christensen, S., Jensen, K.: The practitioner’s guide tocoloured petri nets. International Journal on Software Tools for Tech-nology Transfer 2 (1998) 98–132
[9] Jensen, K.: A brief introduction to coloured petri nets. In: Proceedingof the TACAS’97 Workshop, Enschede, The Netherlands. Volume 1217of Lecture Notes in Computer Science. (1997) 203–208
[10] Weske, M.: Business Process Management: Concepts, Languages, Ar-chitectures. Springer (2007)
[11] Keller, G., Nuttgens, M., Scheer, A.W.: Semantische Prozessmodel-lierung auf der Grundlage “Ereignisgesteuerter Prozessketten (EPK)”.Heft 89, Institut fur Wirtschaftsinformatik, Saarbrucken, Germany(1992)
[12] Scheer, A.W.: ARIS business process modelling. Springer Verlag (2000)
18
[13] Mendling, J., Muehlen, M., Price, A.: Standards for Workflow Definitionand Execution. In: Process Aware Information Systems: Bridging Peo-ple and Software Through Process Technology. Wiley Publishing (2005)
[14] OMG: Business Process Modeling Notation, V1.1. Object ManagementGroup, http://www.omg.org/docs/formal/08-01-17.pdf. (2008)
[15] WG, J.: Mort, safety assurances systems (1980)
[16] Livingston, A.D., Jackson, G., Priestley, K.: Root causes analysis: Lit-erature review. St Clements House (2001)
[17] Johnson, C.W.: Failure in Safety-Critical Systems: A Handbook ofAccident and Incident Reporting. University of Glasgow Press, Glasgow,Scotland (2003)
[18] Benner, L.J.: Accident Investigations: Multilinear Events SequencingMethods. Journal of Safety Research 7 (1975) 67–73
[19] Murayama, Y., Yamazaki, M., Endo: A pilot study on marine incidents.The journal of Japan institute of navigation (1998) 257–264
[20] Hendrick, K., Benner, L.J.: Investigating accidents with s-t-e-p (1987)
[21] Hendric, K., Benner, L.: Investigating Accidents with SequentiallyTimed and Events Plotting (STEP). Marcel Decker (1987)
[22] Talty, J.T.: Industrial Hygiene / Industrial Hygiene Engineering -Recognition, Measurement, Evaluation and Control. William AndrewInc. (1988)
[23] Paradies, M., Unger, L., Haas, P., Terranova, M.: Development of theNRCs Human Performance Investigation Process (HPIP). Summary,Division of Systems Research Office of Nuclear Regulatory Research 1(1993) SI–92–101
[24] Kepner, C., Tregor, B.: The Rational Manager. 2nd Ed, PrincetonNJ,Kepner-Tregoe Inc. (1976)
[25] Samuel, K.M., Samuel, K.H.: Operations and Quality Management.Thomson Learning EMEA (1999)
[26] Lau, R., Anderson, C.: A three-dimensional perspective of total qualitymanagement. International Journal of Quality & Reliability Manage-ment 15 (1998) 85 – 98
19
[27] Wittenberg, G.: Kaizenthe many ways of getting better. AssemblyAutomation 14 (1994) 12 – 17
[28] Snee, R.: Six sigma: the evolution of 100 years of business improve-ment methodology. International Journal of Six Sigma and CompetitiveAdvantage 1 (2004) 4–20
[29] Cornford, S.L., Gibbel, M.: Methodology for physics and engineering ofreliable products. In: In proceedings of WESCON. (1996) 618 – 624
[30] Parry, J., Rantala, J., Lasance, C.: Enhanced electronic system reli-ability - challenges for temperature prediction. Packaging and Manu-facturing Technology, Part A: Packaging Technologies 25 (2002) 533 –538
[31] Upadhyayula, K., Dasgupta, A.: Physics-of-failure guidelines for ac-celerated qualification of electronic systems. Quality and ReliabilityEngineering International 14 (1999) 433 – 447
20
312
Appendix B
Action Research Templates
313
Appendix B.1 Meeting Agenda Template
Company A - Meeting Agenda Date:
Time:
Meeting Purpose:
Meeting Protocol:
Attendees:
Agenda: Agenda 1
Additional Information Special Notes:
314
Appendix B.2 Meeting Notes Template
Meeting Notes Date:
Time:
Attendees:
QUT
Mitra Heravizadeh
Company A
Agenda: 1. Agenda 1
315
Appendix B.3 Invitation Letter
Dear Sir/Madam,
We are writing to invite you part in our research project and to benefit from the insights you can gain through our collaboration. In this research project, we explore innovating ways of improving the quality of business process. The aim is to provide a quality framework that can be easily incorporated into the Business Process Management life cycle. While we have a mature conceptual methodology for this approach, we are now seeking empirical insights into such processes. We would appreciate a conversation which you to briefly introduce you to our methodology and then to jointly identify a process that would benefit from this approach.
Kind Regards,
Mitra Heravizadeh
316
Appendix B.4 Action Research Project Summary
Action Research Project Summary – Quality Aware BPM
Purpose The purpose of this document is to provide a summary of the Quality Aware BPM and the proposed action research project plan.
Introduction In this research project, we explore innovating ways of improving the quality of business process. The aim is to provide a quality framework that can be easily incorporated into the Business Process Management life cycle. While a mature conceptual methodology for this approach has been developed by this research project, empirical insights into such processes will ensure the validity of this framework for a real world problem.
Action research has been selected as the research methodology for this stage of research. Action research is a reflective process of progressive problem solving led by individuals working with others in teams as part of a practice to improve the way they address issues and solve problems. The action research adopted in this research is based on the action research methodology by Susman and Everet [1] which consists of five stages: diagnosis, action planning, action taking, evaluation, and specifying learning. The action research plan for this project which presented in the following section is based on these five stages.
Action Research Plan Action research plan for this collaborative project is presented in Figure 1. As shown in Figure 1, informal meetings and workshops will provide the majority of the interaction mechanism during the project. For meetings and workshops, the agendas will be distributed in advance to appropriate parties, and minutes from the meetings will be recorded using a standard template. Throughout the action research phase, the main researcher will record notes and reflections related to each case. Activities with respect to each stage of the action research plan (Figure 1) are described in detail below.
317
Phase
Sub-Activity
Engagement Type
Duration
Initial Engagement Initial Kick off Informal Meeting 2 hours Action Research Cycle – Diagnosis
Identify the problem Informal Meeting 4 hours
Action Research Cycle – Action Planning
Define the Project Scope
Informal Meeting 1 hour
Plan Activities Informal Meeting 2 hours Schedule Informal Meeting 1 hour
Action Research Cycle – Action Taking Phase I
Analyse the Process Workshop 4 hours Create Business Process Model
Workshop 16 hours
Create Quality Model Workshop 16 hours Create Softgoal Model Workshop 16 hours Create Correlations Model
None 4 hours
Create Measurement Model
Workshop 8 hours
Prepare Project Report None 40 hours Action Research Cycle – Action Taking Phase II
Conduct Root Cause Analysis
Workshop 8 hours
Action Research Cycle – Evaluating
Evaluate QoBP Framework
Workshop 16 hours
Present Evaluation Results
Workshop 20 hours
Action Research Cycle – Specifying Learning
Identify Enhancement Opportunities to QoBP Framework
Workshop
8 hours
Prepare Report None 40 hours Closure Final Meeting
Informal Meeting 4 hours
Initial Engagement
During the initial meeting the action research process and plan will be described by the main researcher to the parties involved.
Diagnosis Stage
Diagnosis is the first stage of the action research cycle. The purpose of this stage is to:
• Describe the purpose of the action research and its benefits to the organisation.
318
• Identify a business process within the organisation that can be improved using the framework proposed by this research.
During this stage, the main researcher will conduct informal meetings with the key stakeholders which are envisaged to be up to 4 hours in duration. During these meetings the main researcher will describe the purpose of the action research, and how the host organisation will benefit by introducing the Quality of Business Process (QoBP) framework to their BPM practice. An appropriate process that will benefit from the QoBP framework will also be selected during these meetings.
Action Planning Stage
The main purpose of this stage is to plan the activities that are performed during the course of the collaboration to solve the identified problem. The activity plan will be based on the activities that are required to be performed for two phases:
• Phase I - To create a quality-aware business process. The activity plan for this phase is based on the procedural steps which are described in the following section.
• Phase II - To conduct root cause analysis in order to improve the quality of a business process during the. The activity plan for this phase is based on the Process Root Cause Analysis technique proposed by this research study.
During this stage, the main researcher will conduct informal meetings with key stakeholders which are envisaged to be up to 4 hours in duration. During these meetings, the main researcher will plan the above activities with the key stakeholders. An action research cycle may only be planned for just one phase (i.e. phase one).
Action Taking Stage
The purpose of this stage is to perform the activities identified during the action planning stage. Accordingly, the main researcher will be organising a series of workshops with the key stakeholders according to the action plan produced during the previous stage. These workshops, in general, have two different focuses: (1) data collection; and (2) validation of the model created after the data collection. The action taking stage is based on the action plan created during the action planning stage. The action taking stage is divided into two phases (based on two phases described in the previous section) which are:
o Action Taking Stage Phase I
1. Analyse the business process - T he purpose of the first step is to analyse the organisation structure, the process goals, the process environment, and the quality requirements of the process being analysed. During this stage, the main researcher will organise a workshop inviting relevant parties to analyse the business process. Accordingly, the functional and quality (non-functional) requirements of the process
- The purpose of this stage is to perform the activities identified for phase I of the action taking stage which are:
319
will be elicited during the workshop, , taking account of the organisation's strategy, goals and structure. The deliverable of this step will be a document describing the functional and quality (non-functional) requirements, in plain English, of the business process being analysed.
2. Define a business process model - The purpose of this step is to model the selected process using a business process modelling language. During this stage, the main researcher will organise a series of workshops inviting relevant parties to model the business process based on the requirements defined and documented during the previous step.
3. Create a quality model - The purpose of this step is to define a quality model for the selected business process. The main researcher will organise four workshops to capture the quality characteristics for the four business process quality dimensions (functions, inputs-outputs, human resources, and non-human resources). The outcome of these workshops is a quality model consisting of the quality characteristics for the four dimensions of the business process.
4. Create a softgoal model - The objective of this step is to create a softgoal model for the quality characteristics modelled in the quality model created in the previous step. Accordingly, the main researcher will organise a series of workshops to specify softgoals for the quality characteristics identified during the previous step.
5. Create a softgoal correlation model - The purpose of this step is to identify the correlations between the softgoals identified during the last step. The main researcher will create the softgoal correlation model based on the algorithm proposed by this research study. No contribution from the host organisation is required for this step.
6. Create a measurement model - The purpose of this step is to create a model which contains metrics required to measure softgoal satisfaction. This step is the last step of the process that transforms the subjective quality characteristics into a set of measurable objective quality metrics. Accordingly, the main researcher will organise a series of workshops to identify quality metrics.
o Action Taking Stage Phase II - The purpose of this stage is to perform the activities identified for phase II of the action taking stage. The PRCA technique proposed by this research provides a step-by-step procedure to identify the root causes of a quality issue for an instance of a process. In order to trace a quality issue back to its root cause for an instance of a business process, the correlations between softgoals that are modelled in a softgoal correlation model for the process are used. The main researcher will organise a series of workshops to conduct root cause analysis for the quality issue that is being investigated. The main researcher will invite the appropriate participants for each workshop based on the information/data that is required to be gathered. It is envisaged that up to 4 workshops of 2 hours each is required to complete this step. She will follow the step-by-step procedures provided by the PRCA technique which are:
320
1. In the softgoal correlation model, find the softgoal that is linked to the quality issue;
2. Trace the softgoal through the softgoal correlation model;
3. Evaluate the traced softgoal and record the results. Softgoal satisfaction is determined by the value at the process instance level for the metric that measures the softgoal satisfaction;
4. Repeat Step 2 and 3 until no more softgoal is traced;
5. Review the results from the evaluation of the traced softgoals;
6. Identify the last softgoal being traced which is not satisfied (meets the failure condition for a metric;
7. Find the quality issue that is linked to the last softgoal that was identified in the previous step. This quality issue is the root quality issue;
8. Find the quality metrics which contributed to the failure of the root quality issue. These quality metrics are the root causes of the investigated quality issue.
Evaluation
The main purpose of this stage is to evaluate the consequences of the actions taken in the previous stage. Accordingly, the main researcher will organise a series of workshops with key participants to thoroughly evaluate the outcome of the action research based on above objectives. The main researcher will use a questionnaire to guide the evaluation process. This questionnaire is created based on a set of evaluation objectives. The answer from each organisation's key participants will be recorded and be used as input for the next stage. It is envisaged that up to 4 workshops of 4 hours each is required to complete this step.
Specifying Learning
The purpose of this step is to identify the lessons learned during the action research cycle. The evaluation results produced during the last stage will influence the discovery of the lessons learned. During this stage, the main researcher will organise a series of workshops with key stakeholders to reflect on the evaluation results. The lessons learned and possible enhancements to the QoBP framework and PRCA approach will be identified during these workshops. The enhancement opportunities identified for artifacts being evaluated will be used to enhance the relevant artifacts. It is envisaged that up to 2 workshops of 4 hours each is required to complete this step.
Closure
321
During this last stage of the action research, the main researcher will organise an informal meeting to express her appreciation to the key stakeholders contributing to this collaborative project.
References [1] Susman, G., Evered, R.: An assessment of the scientific merits of action research. Information Systems
Journal 4 (1978) 582--603
322
Appendix B.5 Evaluation Questions
Evaluation Questions:
1. Quality model:
a. Were function quality characteristics applicable to the function quality dimension?
b. Were input & output quality characteristics applicable to the input & out quality dimension?
c. Were human resource quality characteristics applicable to the human resource quality dimension?
d. Were non-human resource quality characteristics applicable to the non-human resource quality dimension?
e. Were the supporting methodology and templates to identify and capture quality characteristics for the function quality dimension usable and scalable?
f. Were the supporting methodology and templates to identify and capture quality characteristics for the input & output quality dimension usable and scalable?
g. Were the supporting methodology and templates to identify and capture quality characteristics for the function human resource dimension usable and scalable?
h. Were the supporting methodology and templates to identify and capture quality characteristics for the function non-human resource dimension usable and scalable?
2. Softgoal model:
a. Were the supporting methodology and templates to identify and capture softgoals for functions quality characteristics usable and scalable?
b. Were the supporting methodology and templates to identify and capture softgoals for inputs & outputs quality characteristics usable and scalable?
c. Were the supporting methodology and templates to identify and capture softgoals for human resource quality characteristics usable and scalable?
d. Were the supporting methodology and templates to identify and capture softgoals for non-human resource quality characteristics usable and scalable?
3. Correlation model:
a. Were the supporting methodology and templates to identify and capture correlations between softgoals usable and scalable?
323
4. Measurement model:
a. Were the supporting methodology and templates to identify and capture metrics for softgoals usable and scalable?
b. Is the goal-oriented approach used to identify metrics for softgoals a valid approach?
5. QoBP metamodel:
a. Did QoBP metamodel produce a quality-aware business process?
6. PRCA Approach:
a. Did the PRCA approach provide the investigators the ability to identify the sequence of events leading to a cause of an issue?
b. Did the PRCA approach provide the investigators the context required to conduct corrective actions?
c. Did the PRCA approach provide a systematic methodology to conduct the investigation?
d. Did the PRCA approach provide a consistent mechanism for investigators to detect the root cause of an issue?
e. Was the PRCA approach easy to learn and easy to use?
324
Appendix C
Action Research Organisation A
325
Appendix C.1 Functions Softgoal Model
Organisation A – Functions Softgoal Model
Functions Quality Characteristics Soft Goals
F1 - Obtain policy details and validate caller (authorised to lodge)
Suitability To improve the suitability of the ‘Obtain policy details and validate caller’ function.
Reliability To improve the reliability of the ‘Obtain policy details and validate caller’ function.
Productivity To increase the productivity of the ‘Obtain policy details and validate caller’ function.
F2 - Validate Policy Suitability To improve the suitability of the ‘Validate policy’ function.
Reliability To improve the reliability of the ‘Validate policy’ function.
Productivity To increase the productivity of the ‘Validate policy’ function.
F3 - Capture incident details
Suitability To improve the suitability of the ‘Capture incident details’ function.
Understandability To improve the understandability of the ‘Capture incident details’ function.
Productivity To increase the productivity of the ‘Capture incident details’ function.
F4 - Validate incident coverage
Accuracy To improve the accuracy of ‘Validate incident coverage’ function.
Reliability To improve the reliability of ‘Validate incident coverage’ function.
Understandability To improve the understandability of the ‘Validate incident coverage’ function.
F5 - Assess liability Accuracy To improve the accuracy of the ‘Assess liability’ function.
Reliability To improve the reliability of the ‘Assess liability’ function.
Robustness To improve the robustness of the ‘Assess liability’ function.
F6 - Capture loss and TP details
Suitability To improve the suitability of the ‘Capture loss and TP details’ function.
Understandability To improve the understandability of the ‘Capture loss and TP details’ function.
Productivity To increase the productivity of the ‘Capture loss and TP details’ function.
F7 - Assess excess Accuracy To improve the accuracy of the ‘Assess excess’ function.
Reliability To improve the reliability of the ‘Assess excess’ function.
Robustness To improve the robustness of the ‘Assess excess’ function.
F8 - Assess pathing Accuracy To improve the accuracy of the ‘Assess pathing’ function.
Reliability To improve the reliability of the ‘Assess pathing’ function.
326
Productivity To increase the productivity of the ‘Assess pathing’ function.
F9 - Action hire car and towing (as appropriate)
Suitability To improve the suitability of the ‘Action hire car and towing’ function.
Understandability To improve the understandability of the ‘Action hire car and towing’ function.
Learnability To improve the learnability of the ‘Action hire car and towing’ function.
F10 - Add authorised parties (as appropriate)
Suitability To improve the suitability of the ‘Add authorised parties’ function.
Security To improve the security of the ‘Add authorised parties’ function.
Understandability To improve the understandability of the ‘Add authorised parties’ function.
F11 - Inform customer of next steps
Suitability To improve the suitability of the ‘Inform customer of next steps’ function.
Accuracy To improve the accuracy of the ‘Inform customer of next steps’ function.
Understandability To improve the understandability of the ‘Inform customer of next steps’ function.
F12 - Finalise claim intake Accuracy To improve the accuracy of the ‘Finalise claim intake’ function.
Reliability To improve the reliability of the ‘Finalise claim intake’ function.
Effectiveness To improve the effectiveness of the ‘Finalise claim intake’ function.
327
Appendix C.2 Input & Output Softgoal Model
Organisation A – Input & Output Softgoal Model
Function Input/Output Data
Quality Characteristics
Soft Goals
F1 - Obtain policy details and validate caller (authorised to lodge)
Customer Identification
Accuracy To improve the accuracy of the ‘Customer Identification’ data of the ‘Obtain policy details and validate caller’ function.
Objectivity To improve the objectivity of the ‘Customer Identification’ data of the ‘Obtain policy details and validate caller’ function.
Believability To improve the believability of the ‘Customer Identification’ data of the ‘Obtain policy details and validate caller’ function.
Reputation To improve the reputation of the ‘Customer Identification’ data of the ‘Obtain policy details and validate caller’ function.
Relevancy To improve the relevancy of the ‘Customer Identification’ data of the ‘Obtain policy details and validate caller’ function.
Timeliness To improve the timeliness of the ‘Customer Identification’ data of the ‘Obtain policy details and validate caller’ function.
Completeness To improve the completeness of the ‘Customer Identification’ data of the ‘Obtain policy details and validate caller’ function.
Amount of Data
To improve the amount of data of the ‘Customer Identification’ data of the ‘Obtain policy details and validate caller’ function.
Accessibility To improve the accessibility of the ‘Customer Identification’ data of the ‘Obtain policy details and validate caller’ function.
Customer Products
Accuracy To improve the accuracy of the ‘Customer Products’ data of the ‘Obtain policy details and validate caller’ function.
Objectivity To improve the objectivity of the ‘Customer Products’ data of the ‘Obtain policy details and validate caller’ function.
Believability To improve the believability of the ‘Customer Products’ data of the ‘Obtain policy details and validate caller’ function.
Reputation To improve the reputation of the ‘Customer Products’ data of the ‘Obtain policy details and validate caller’ function.
Relevancy To improve the relevancy of the ‘Customer Products’ data of the ‘Obtain policy details and validate caller’ function.
Security To increase the security of the ‘Customer Products’ data of the ‘Obtain policy details and validate caller’
328
function.
Timeliness To improve the timeliness of the ‘Customer Products’ data of the ‘Obtain policy details and validate caller’ function.
Completeness To improve the completeness of the ‘Customer Products’ data of the ‘Obtain policy details and validate caller’ function.
Amount of Data
To improve the amount of data of the ‘Customer Products’ data of the ‘Obtain policy details and validate caller’ function.
Accessibility To improve the accessibility of the ‘Customer Products’ data of the ‘Obtain policy details and validate caller’ function.
Policy Identification
Accuracy To improve the accuracy of the ‘Policy Identification’ data of the ‘Obtain policy details and validate caller’ function.
Objectivity To improve the objectivity of the ‘Policy Identification’ data of the ‘Obtain policy details and validate caller’ function.
Believability To improve the believability of the ‘Policy Identification’ data of the ‘Obtain policy details and validate caller’ function.
Reputation To improve the reputation of the ‘Policy Identification’ data of the ‘Obtain policy details and validate caller’ function.
Relevancy To improve the relevancy of the ‘Policy Identification’ data of the ‘Obtain policy details and validate caller’ function.
Security To increase the security of the ‘Policy Identification’ data of the ‘Obtain policy details and validate caller’ function.
Timeliness To improve the timeliness of the ‘Policy Identification’ data of the ‘Obtain policy details and validate caller’ function.
Completeness To improve the completeness of the ‘Policy Identification’ data of the ‘Obtain policy details and validate caller’ function.
Amount of Data
To improve the amount of data of the ‘Policy Identification’ data of the ‘Obtain policy details and validate caller’ function.
Accessibility To improve the accessibility of the ‘Policy Identification’ data of the ‘Obtain policy details and validate caller’ function.
F2 - Validate Policy
Policy Identification
Accuracy To improve the accuracy of the ‘Policy Identification’ data of the ‘Validate policy’ function.
Objectivity To improve the objectivity of the ‘Policy Identification’ data of the ‘Validate policy’ function.
Believability To improve the believability of the ‘Policy Identification’ data of the ‘Validate policy’ function.
Reputation To improve the reputation of the ‘Policy Identification’ data of the ‘Validate policy’ function.
Relevancy To improve the relevancy of the ‘Policy Identification’ data of the ‘Validate policy’ function.
Security To increase the security of the ‘Policy Identification’ data of the ‘Validate policy’ function.
329
Timeliness To improve the timeliness of the ‘Policy Identification’ data of the ‘Validate policy’ function.
Completeness To improve the completeness of the ‘Policy Identification’ data of the ‘Validate policy’ function.
Amount of Data
To improve the amount of data of the ‘Policy Identification’ data of the ‘Validate policy’ function.
Accessibility To improve the accessibility of the ‘Policy Identification’ data of the ‘Validate policy’ function.
Coverage and Policy Extras
Accuracy To improve the accuracy of the ‘Coverage and Policy Extras’ data of the ‘Validate policy’ function.
Objectivity To improve the objectivity of the ‘Coverage and Policy Extras’ data of the ‘Validate policy’ function.
Believability To improve the believability of the ‘Coverage and Policy Extras’ data of the ‘Validate policy’ function.
Reputation To improve the reputation of the ‘Coverage and Policy Extras’ data of the ‘Validate policy’ function.
Relevancy To improve the relevancy of the ‘Coverage and Policy Extras’ data of the ‘Validate policy’ function.
Security To increase the security of the ‘Coverage and Policy Extras’ data of the ‘Validate policy’ function.
Timeliness To improve the timeliness of the ‘Coverage and Policy Extras’ data of the ‘Validate policy’ function.
Completeness To improve the completeness of the ‘Coverage and Policy Extras’ data of the ‘Validate policy’ function.
Amount of Data
To improve the amount of data of the ‘Coverage and Policy Extras’ data of the ‘Validate policy’ function.
Accessibility To improve the accessibility of the ‘Coverage and Policy Extras’ data of the ‘Validate policy’ function.
Vehicle Identification
Reputation To improve the reputation of the ‘Vehicle Identification’ data of the ‘Validate policy’ function.
Relevancy To improve the relevancy of the ‘Vehicle Identification’ data of the ‘Validate policy’ function.
Timeliness To improve the timeliness of the ‘Vehicle Identification’ data of the ‘Validate policy’ function.
Completeness To improve the completeness of the ‘Vehicle Identification’ data of the ‘Validate policy’ function.
Amount of Data
To improve the amount of data of the ‘Vehicle Identification’ data of the ‘Validate policy’ function.
F3 - Capture incident details
Incident Details Accuracy To improve the accuracy of the ‘Incident Details’ data of the ‘Capture incident details’ function.
Objectivity To improve the objectivity of the ‘Incident Details’ data of the ‘Capture incident details’ function.
Believability To improve the believability of the ‘Incident Details’ data of the ‘Capture incident details’ function.
Reputation To improve the reputation of the ‘Incident Details’ data of the ‘Capture incident details’ function.
Relevancy To improve the relevancy of the ‘Incident Details’ data of the ‘Capture incident details’ function.
Value-added To increase the value-added of the ‘Incident Details’ data of the ‘Capture incident details’ function.
Security To increase the security of the ‘Incident Details’ data of the ‘Capture incident details’ function.
Timeliness To improve the timeliness of the ‘Incident Details’ data of the ‘Capture incident details’ function.
Completeness To improve the completeness of the ‘Incident
330
Details’ data of the ‘Capture incident details’ function.
Amount of Data
To improve the amount of data of the ‘Incident Details’ data of the ‘Capture incident details’ function.
Accessibility To improve the accessibility of the ‘Incident Details’ data of the ‘Capture incident details’ function.
F4 - Validate incident coverage
Coverage and Policy Extras
Accuracy To improve the accuracy of the ‘Coverage and Policy Extras’ data of the ‘Validate incident coverage’ function.
Objectivity To improve the objectivity of the ‘Coverage and Policy Extras’ data of the ‘Validate incident coverage’ function.
Believability To improve the believability of the ‘Coverage and Policy Extras’ data of the ‘Validate incident coverage’ function.
Reputation To improve the reputation of the ‘Coverage and Policy Extras’ data of the ‘Validate incident coverage’ function.
Accessibility To improve the accessibility of the ‘Coverage and Policy Extras’ data of the ‘Validate incident coverage’ function.
Relevancy To improve the relevancy of the ‘Coverage and Policy Extras’ data of the ‘Validate incident coverage’ function.
Security To increase the security of the ‘Coverage and Policy Extras’ data of the ‘Validate incident coverage’ function.
Completeness To improve the completeness of the ‘Coverage and Policy Extras’ data of the ‘Validate incident coverage’ function.
Amount of Data
To improve the amount of data of the ‘Coverage and Policy Extras’ data of the ‘Validate incident coverage’ function.
Timeliness To improve the timeliness of the ‘Coverage and Policy Extras’ data of the ‘Validate incident coverage’ function.
Claim Business Rules
Accuracy To improve the accuracy of the ‘Claim Business Rules’ data of the ‘Validate incident coverage’ function.
Objectivity To improve the objectivity of the ‘Claim Business Rules’ data of the ‘Validate incident coverage’ function.
Believability To improve the believability of the ‘Claim Business Rules’ data of the ‘Validate incident coverage’ function.
Reputation To improve the reputation of the ‘Claim Business Rules’ data of the ‘Validate incident coverage’ function.
Accessibility To improve the accessibility of the ‘Claim Business Rules’ data of the ‘Validate incident coverage’ function.
Relevancy To improve the relevancy of the ‘Claim Business Rules’ data of the ‘Validate incident coverage’ function.
331
Value-added To increase the value-added of the ‘Claim Business Rules’ data of the ‘Validate incident coverage’ function.
Security To increase the secirity of the ‘Claim Business Rules’ data of the ‘Validate incident coverage’ function.
Completeness To improve the completeness of the ‘Claim Business Rules’ data of the ‘Validate incident coverage’ function.
Amount of Data
To improve the amount of data of the ‘Claim Business Rules’ data of the ‘Validate incident coverage’ function.
Timeliness To improve the timeliness of the ‘Claim Business Rules’ data of the ‘Validate incident coverage’ function.
F5 - Assess liability
Incident Details Accuracy To improve the accuracy of the ‘Incident Details’ data of the ‘Assess liability’ function.
Objectivity To improve the objectivity of the ‘Incident Details’ data of the ‘Assess liability’ function.
Believability To improve the believability of the ‘Incident Details’ data of the ‘Assess liability’ function.
Reputation To improve the reputation of the ‘Incident Details’ data of the ‘Assess liability’ function.
Accessibility To improve the accessibility of the ‘Incident Details’ data of the ‘Assess liability’ function.
Relevancy To improve the relevancy of the ‘Incident Details’ data of the ‘Assess liability’ function.
Value-added To increase the value-added of the ‘Incident Details’ data of the ‘Assess liability’ function.
Security To increase the security of the ‘Incident Details’ data of the ‘Assess liability’ function.
Completeness To improve the completeness of the ‘Incident Details’ data of the ‘Assess liability’ function.
Amount of Data
To improve the amount of data of the ‘Incident Details’ data of the ‘Assess liability’ function.
Timeliness To improve the timeliness of the ‘Incident Details’ data of the ‘Assess liability’ function.
Claim Business Rules
Accuracy To improve the accuracy of the ‘Claim Business Rules’ data of the ‘Assess liability’ function.
Objectivity To improve the objectivity of the ‘Claim Business Rules’ data of the ‘Assess liability’ function.
Believability To improve the believability of the ‘Claim Business Rules’ data of the ‘Assess liability’ function.
Reputation To improve the reputation of the ‘Claim Business Rules’ data of the ‘Assess liability’ function.
Accessibility To improve the accessibility of the ‘Claim Business Rules’ data of the ‘Assess liability’ function.
Relevancy To improve the relevancy of the ‘Claim Business Rules’ data of the ‘Assess liability’ function.
Value-added To increase the value-added of the ‘Claim Business Rules’ data of the ‘Assess liability’ function.
Security To increase the security of the ‘Claim Business Rules’ data of the ‘Assess liability’ function.
Completeness To improve the completeness of the ‘Claim Business Rules’ data of the ‘Assess liability’ function.
Amount of Data
To improve the amount of data of the ‘Claim Business Rules’ data of the ‘Assess liability’ function.
332
Timeliness To improve the timeliness of the ‘Claim Business Rules’ data of the ‘Assess liability’ function.
F6 - Capture loss and TP details
Vehicle Identification
Reputation To improve the reputation of the ‘Vehicle Identification’ data of the ‘Capture loss and TP details’ function.
Relevancy To improve the relevancy of the ‘Vehicle Identification’ data of the ‘Capture loss and TP details’ function.
Timeliness To improve the timeliness of the ‘Vehicle Identification’ data of the ‘Capture loss and TP details’ function.
Completeness To improve the completeness of the ‘Vehicle Identification’ data of the ‘Capture loss and TP details’ function.
Amount of Data
To improve the amount of data of the ‘Vehicle Identification’ data of the ‘Capture loss and TP details’ function.
Driver Details Reputation To improve the reputation of the ‘Driver Details’ data of the ‘Capture loss and TP details’ function.
Relevancy To improve the relevancy of the ‘Driver Details’ data of the ‘Capture loss and TP details’ function.
Security To increase the security of the ‘Driver Details’ data of the ‘Capture loss and TP details’ function.
Timeliness To improve the timeliness of the ‘Driver Details’ data of the ‘Capture loss and TP details’ function.
Completeness To improve the completeness of the ‘Driver Details’ data of the ‘Capture loss and TP details’ function.
Amount of Data
To improve the amount of data of the ‘Driver Details’ data of the ‘Capture loss and TP details’ function.
Accessibility To improve the accessibility of the ‘Driver Details’ data of the ‘Capture loss and TP details’ function.
Customer Vehicle Details - Damage
Accuracy To improve the accuracy of the ‘Customer Vehicle Details - Damage’ data of the ‘Capture loss and TP details’ function.
Objectivity To improve the objectivity of the ‘Customer Vehicle Details - Damage’ data of the ‘Capture loss and TP details’ function.
Believability To improve the believability of the ‘Customer Vehicle Details - Damage’ data of the ‘Capture loss and TP details’ function.
Reputation To improve the reputation of the ‘Customer Vehicle Details - Damage’ data of the ‘Capture loss and TP details’ function.
Relevancy To improve the relevancy of the ‘Customer Vehicle Details - Damage’ data of the ‘Capture loss and TP details’ function.
Security To increase the security of the ‘Customer Vehicle Details - Damage’ data of the ‘Capture loss and TP details’ function.
Timeliness To improve the timeliness of the ‘Customer Vehicle Details - Damage’ data of the ‘Capture loss and TP details’ function.
Completeness To improve the completeness of the ‘Customer Vehicle Details - Damage’ data of the ‘Capture loss and TP details’ function.
333
Amount of Data
To improve the amount of data of the ‘Customer Vehicle Details - Damage’ data of the ‘Capture loss and TP details’ function.
Accessibility To improve the accessibility of the ‘Customer Vehicle Details - Damage’ data of the ‘Capture loss and TP details’ function.
Customer Personal Property
Reputation To improve the reputation of the ‘Customer Personal Property’ data of the ‘Capture loss and TP details’ function.
Relevancy To improve the relevancy of the ‘Customer Personal Property’ data of the ‘Capture loss and TP details’ function.
Security To increase the security of the ‘Customer Personal Property’ data of the ‘Capture loss and TP details’ function.
Timeliness To improve the timeliness of the ‘Customer Personal Property’ data of the ‘Capture loss and TP details’ function.
Accessibility To improve the accessibility of the ‘Customer Personal Property’ data of the ‘Capture loss and TP details’ function.
Third Party Details Relevancy To improve the relevancy of the ‘Third Party Details’ data of the ‘Capture loss and TP details’ function.
Value-added To increase the value-added of the ‘Third Party Details’ data of the ‘Capture loss and TP details’ function.
Security To increase the security of the ‘Third Party Details’ data of the ‘Capture loss and TP details’ function.
Timeliness To improve the timeliness of the ‘Third Party Details’ data of the ‘Capture loss and TP details’ function.
Completeness To improve the completeness of the ‘Third Party Details’ data of the ‘Capture loss and TP details’ function.
Amount of Data
To improve the amount of data of the ‘Third Party Details’ data of the ‘Capture loss and TP details’ function.
Accessibility To improve the accessibility of the ‘Third Party Details’ data of the ‘Capture loss and TP details’ function.
Other Party Details
Objectivity To improve the objectivity of the ‘Other Party Details’ data of the ‘Capture loss and TP details’ function.
Believability To improve the believability of the ‘Other Party Details’ data of the ‘Capture loss and TP details’ function.
Relevancy To improve the relevancy of the ‘Other Party Details’ data of the ‘Capture loss and TP details’ function.
Security To increase the security of the ‘Other Party Details’ data of the ‘Capture loss and TP details’ function.
Timeliness To improve the timeliness of the ‘Other Party Details’ data of the ‘Capture loss and TP details’ function.
Completeness To improve the completeness of the ‘Other Party Details’ data of the ‘Capture loss and TP details’ function.
334
Amount of Data
To improve the amount of data of the ‘Other Party Details’ data of the ‘Capture loss and TP details’ function.
F7 - Assess excess Coverage and Policy Extras
Accuracy To improve the accuracy of the ‘Coverage and Policy Extras’ data of the ‘Assess excess’ function.
Objectivity To improve the objectivity of the ‘Coverage and Policy Extras’ data of the ‘Assess excess’ function.
Believability To improve the believability of the ‘Coverage and Policy Extras’ data of the ‘Assess excess’ function.
Reputation To improve the reputation of the ‘Coverage and Policy Extras’ data of the ‘Assess excess’ function.
Accessibility To improve the accessibility of the ‘Coverage and Policy Extras’ data of the ‘Assess excess’ function.
Relevancy To improve the relevancy of the ‘Coverage and Policy Extras’ data of the ‘Assess excess’ function.
Security To increase the security of the ‘Coverage and Policy Extras’ data of the ‘Assess excess’ function.
Completeness To improve the completeness of the ‘Coverage and Policy Extras’ data of the ‘Assess excess’ function.
Amount of Data
To improve the amount of data of the ‘Coverage and Policy Extras’ data of the ‘Assess excess’ function.
Timeliness To improve the timeliness of the ‘Coverage and Policy Extras’ data of the ‘Assess excess’ function.
Vehicle Information
Accuracy To improve the accuracy of the ‘Vehicle Information’ data of the ‘Assess excess’ function.
Objectivity To improve the objectivity of the ‘Vehicle Information’ data of the ‘Assess excess’ function.
Believability To improve the believability of the ‘Vehicle Information’ data of the ‘Assess excess’ function.
Reputation To improve the reputation of the ‘Vehicle Information’ data of the ‘Assess excess’ function.
Relevancy To improve the relevancy of the ‘Vehicle Information’ data of the ‘Assess excess’ function.
Completeness To improve the completeness of the ‘Vehicle Information’ data of the ‘Assess excess’ function.
Amount of Data
To improve the amount of data of the ‘Vehicle Information’ data of the ‘Assess excess’ function.
Timeliness To improve the timeliness of the ‘Vehicle Information’ data of the ‘Assess excess’ function.
Incident Details Accuracy To improve the accuracy of the ‘Incident Details’ data of the ‘Assess excess’ function.
Objectivity To improve the objectivity of the ‘Incident Details’ data of the ‘Assess excess’ function.
Believability To improve the believability of the ‘Incident Details’ data of the ‘Assess excess’ function.
Reputation To improve the reputation of the ‘Incident Details’ data of the ‘Assess excess’ function.
Accessibility To improve the accessibility of the ‘Incident Details’ data of the ‘Assess excess’ function.
Relevancy To improve the relevancy of the ‘Incident Details’ data of the ‘Assess excess’ function.
Value-added To increase the value-added of the ‘Incident Details’ data of the ‘Assess excess’ function.
Completeness To improve the completeness of the ‘Incident Details’ data of the ‘Assess excess’ function.
335
Amount of Data
To improve the amount of data of the ‘Incident Details’ data of the ‘Assess excess’ function.
Timeliness To improve the timeliness of the ‘Incident Details’ data of the ‘Assess excess’ function.
Claim Business Rules
Accuracy To improve the accuracy of the ‘Claim Business Rules’ data of the ‘Assess excess’ function.
Objectivity To improve the objectivity of the ‘Claim Business Rules’ data of the ‘Assess excess’ function.
Believability To improve the believability of the ‘Claim Business Rules’ data of the ‘Assess excess’ function.
Reputation To improve the reputation of the ‘Claim Business Rules’ data of the ‘Assess excess’ function.
Accessibility To improve the accessibility of the ‘Claim Business Rules’ data of the ‘Assess excess’ function.
Relevancy To improve the relevancy of the ‘Claim Business Rules’ data of the ‘Assess excess’ function.
Value-added To increase the value-added of the ‘Claim Business Rules’ data of the ‘Assess excess’ function.
Security To increase the security of the ‘Claim Business Rules’ data of the ‘Assess excess’ function.
Completeness To improve the completeness of the ‘Claim Business Rules’ data of the ‘Assess excess’ function.
Amount of Data
To improve the amount of data of the ‘Claim Business Rules’ data of the ‘Assess excess’ function.
Timeliness To improve the timeliness of the ‘Claim Business Rules’ data of the ‘Assess excess’ function.
F8 - Assess pathing
Incident Details Accuracy To improve the accuracy of the ‘Incident Details’ data of the ‘Assess pathing’ function.
Objectivity To improve the objectivity of the ‘Incident Details’ data of the ‘Assess pathing’ function.
Believability To improve the believability of the ‘Incident Details’ data of the ‘Assess pathing’ function.
Reputation To improve the reputation of the ‘Incident Details’ data of the ‘Assess pathing’ function.
Accessibility To improve the accessibility of the ‘Incident Details’ data of the ‘Assess pathing’ function.
Relevancy To improve the relevancy of the ‘Incident Details’ data of the ‘Assess pathing’ function.
Value-added To increase the value-added of the ‘Incident Details’ data of the ‘Assess pathing’ function.
Security To increase the security of the ‘Incident Details’ data of the ‘Assess pathing’ function.
Completeness To improve the completeness of the ‘Incident Details’ data of the ‘Assess pathing’ function.
Amount of Data
To improve the amount of data of the ‘Incident Details’ data of the ‘Assess pathing’ function.
Timeliness To improve the timeliness of the ‘Incident Details’ data of the ‘Assess pathing’ function.
Customer Vehicle Details - Damage
Accuracy To improve the accuracy of the ‘Customer Vehicle Details - Damage’ data of the ‘Assess pathing’ function.
Objectivity To improve the objectivity of the ‘Customer Vehicle Details - Damage’ data of the ‘Assess pathing’ function.
Believability To improve the believability of the ‘Customer Vehicle Details - Damage’ data of the ‘Assess pathing’
336
function.
Reputation To improve the reputation of the ‘Customer Vehicle Details - Damage’ data of the ‘Assess pathing’ function.
Accessibility To improve the accessibility of the ‘Customer Vehicle Details - Damage’ data of the ‘Assess pathing’ function.
Relevancy To improve the relevancy of the ‘Customer Vehicle Details - Damage’ data of the ‘Assess pathing’ function.
Security To increase the security of the ‘Customer Vehicle Details - Damage’ data of the ‘Assess pathing’ function.
Completeness To improve the completeness of the ‘Customer Vehicle Details - Damage’ data of the ‘Assess pathing’ function.
Amount of Data
To improve the amount of data of the ‘Customer Vehicle Details - Damage’ data of the ‘Assess pathing’ function.
Timeliness To improve the timeliness of the ‘Customer Vehicle Details - Damage’ data of the ‘Assess pathing’ function.
Assessment Details
Accuracy To improve the accuracy of the ‘Assessment Details’ data of the ‘Assess pathing’ function.
Objectivity To improve the objectivity of the ‘Assessment Details’ data of the ‘Assess pathing’ function.
Believability To improve the believability of the ‘Assessment Details’ data of the ‘Assess pathing’ function.
Reputation To improve the reputation of the ‘Assessment Details’ data of the ‘Assess pathing’ function.
Accessibility To improve the accessibility of the ‘Assessment Details’ data of the ‘Assess pathing’ function.
Relevancy To improve the relevancy of the ‘Assessment Details’ data of the ‘Assess pathing’ function.
Value-added To increase the value-added of the ‘Assessment Details’ data of the ‘Assess pathing’ function.
Completeness To improve the completeness of the ‘Assessment Details’ data of the ‘Assess pathing’ function.
Amount of Data
To improve the amount of data of the ‘Assessment Details’ data of the ‘Assess pathing’ function.
Timeliness To improve the timeliness of the ‘Assessment Details’ data of the ‘Assess pathing’ function.
F9 - Action hire car and towing (as appropriate)
Coverage and Policy Extras
Accuracy To improve the accuracy of the ‘Coverage and Policy Extras’ data of the ‘Action hire car and towing’ function.
Objectivity To improve the objectivity of the ‘Coverage and Policy Extras’ data of the ‘Action hire car and towing’ function.
Believability To improve the believability of the ‘Coverage and Policy Extras’ data of the ‘Action hire car and towing’ function.
Reputation To improve the reputation of the ‘Coverage and Policy Extras’ data of the ‘Action hire car and towing’ function.
Relevancy To improve the relevancy of the ‘Coverage and Policy
337
Extras’ data of the ‘Action hire car and towing’ function.
Security To increase the security of the ‘Coverage and Policy Extras’ data of the ‘Action hire car and towing’ function.
Timeliness To improve the timeliness of the ‘Coverage and Policy Extras’ data of the ‘Action hire car and towing’ function.
Completeness To improve the completeness of the ‘Coverage and Policy Extras’ data of the ‘Action hire car and towing’ function.
Amount of Data
To improve the amount of data of the ‘Coverage and Policy Extras’ data of the ‘Action hire car and towing’ function.
Customer Vehicle Details - Damage
Accuracy To improve the accuracy of the ‘Customer Vehicle Details - Damage’ data of the ‘Action hire car and towing’ function.
Objectivity To improve the objectivity of the ‘Customer Vehicle Details - Damage’ data of the ‘Action hire car and towing’ function.
Believability To improve the believability of the ‘Customer Vehicle Details - Damage’ data of the ‘Action hire car and towing’ function.
Reputation To improve the reputation of the ‘Customer Vehicle Details - Damage’ data of the ‘Action hire car and towing’ function.
Relevancy To improve the relevancy of the ‘Customer Vehicle Details - Damage’ data of the ‘Action hire car and towing’ function.
Security To increase the security of the ‘Customer Vehicle Details - Damage’ data of the ‘Action hire car and towing’ function.
Timeliness To improve the timeliness of the ‘Customer Vehicle Details - Damage’ data of the ‘Action hire car and towing’ function.
Completeness To improve the completeness of the ‘Customer Vehicle Details - Damage’ data of the ‘Action hire car and towing’ function.
Amount of Data
To improve the amount of data of the ‘Customer Vehicle Details - Damage’ data of the ‘Action hire car and towing’ function.
Claim Services Accuracy To improve the accuracy of the ‘Claim Services’ data of the ‘Action hire car and towing’ function.
Objectivity To improve the objectivity of the ‘Claim Services’ data of the ‘Action hire car and towing’ function.
Believability To improve the believability of the ‘Claim Services’ data of the ‘Action hire car and towing’ function.
Reputation To improve the reputation of the ‘Claim Services’ data of the ‘Action hire car and towing’ function.
Relevancy To improve the relevancy of the ‘Claim Services’ data of the ‘Action hire car and towing’ function.
Accessibility To improve the assessibility of the ‘Claim Services’ data of the ‘Action hire car and towing’ function.
Value-added To increase the value-added of the ‘Claim Services’ data of the ‘Action hire car and towing’ function.
338
Timeliness To improve the timeliness of the ‘Claim Services’ data of the ‘Action hire car and towing’ function.
Completeness To improve the completeness of the ‘Claim Services’ data of the ‘Action hire car and towing’ function.
Amount of Data
To improve the amount of data of the ‘Claim Services’ data of the ‘Action hire car and towing’ function.
F10 - Add authorised parties (as appropriate)
Other Party Details
Reputation To improve the reputation of the ‘Other Party Details’ data of the ‘Add authorised parties’ function.
Relevancy To improve the relevancy of the ‘Other Party Details’ data of the ‘Add authorised parties’ function.
Accessibility To improve the accessibility of the ‘Other Party Details’ data of the ‘Add authorised parties’ function.
Security To improve the security of the ‘Other Party Details’ data of the ‘Add authorised parties’ function.
F11 - Inform customer of next steps
Claim Services Accuracy To improve the accuracy of the ‘Claim Services’ data of the ‘Inform customer of next steps’ function.
Objectivity To improve the objectivity of the ‘Claim Services’ data of the ‘Inform customer of next steps’ function.
Believability To improve the believability of the ‘Other Party Details’ data of the ‘Capture loss and TP details’ function.
Reputation To improve the reputation of the ‘Claim Services’ data of the ‘Inform customer of next steps’ function.
Relevancy To improve the relevancy of the ‘Claim Services’ data of the ‘Inform customer of next steps’ function.
Accessibility To improve the accessibility of the ‘Claim Services’ data of the ‘Inform customer of next steps’ function.
Value-added To increase the value-added of the ‘Claim Services’ data of the ‘Inform customer of next steps’ function.
Timeliness To improve the timeliness of the ‘Claim Services’ data of the ‘Inform customer of next steps’ function.
Completeness To improve the completeness of the ‘Claim Services’ data of the ‘Inform customer of next steps’ function.
Amount of Data
To improve the amount of data of the ‘Claim Services’ data of the ‘Inform customer of next steps’ function.
Assessment Details
Accuracy To improve the accuracy of the ‘Assessment Details’ data of the ‘Inform customer of next steps’ function.
Objectivity To improve the objectivity of the ‘Assessment Details’ data of the ‘Inform customer of next steps’ function.
Believability To improve the believability of the ‘Assessment Details’ data of the ‘Inform customer of next steps’ function.
Reputation To improve the reputation of the ‘Assessment Details’ data of the ‘Inform customer of next steps’ function.
Relevancy To improve the relevancy of the ‘Assessment Details’ data of the ‘Inform customer of next steps’ function.
Accessibility To increase the accessibility of the ‘Assessment Details’ data of the ‘Inform customer of next steps’ function.
339
Value-added To increase the value-added of the ‘Assessment Details’ data of the ‘Inform customer of next steps’ function.
Timeliness To improve the timeliness of the ‘Assessment Details’ data of the ‘Inform customer of next steps’ function.
Completeness To improve the completeness of the ‘Assessment Details’ data of the ‘Inform customer of next steps’ function.
Amount of Data
To improve the amount of data of the ‘Assessment Details’ data of the ‘Inform customer of next steps’ function.
F12 - Finalise claim intake
Incident Details Accuracy To improve the accuracy of the ‘Incident Details’ data of the ‘Finalise claim intake’ function.
Objectivity To improve the objectivity of the ‘Incident Details’ data of the ‘Finalise claim intake’ function.
Believability To improve the believability of the ‘Incident Details’ data of the ‘Finalise claim intake’ function.
Reputation To improve the reputation of the ‘Incident Details’ data of the ‘Finalise claim intake’ function.
Accessibility To improve the accessibility of the ‘Incident Details’ data of the ‘Finalise claim intake’ function.
Relevancy To improve the relevancy of the ‘Incident Details’ data of the ‘Finalise claim intake’ function.
Value-added To increase the value-added of the ‘Incident Details’ data of the ‘Finalise claim intake’ function.
Completeness To improve the completeness of the ‘Incident Details’ data of the ‘Finalise claim intake’ function.
Amount of Data
To improve the amount of data of the ‘Incident Details’ data of the ‘Finalise claim intake’ function.
Third Party Details Accuracy To improve the accuracy of the ‘Third Party Details’ data of the ‘Finalise claim intake’ function.
Objectivity To improve the objectivity of the ‘Third Party Details’ data of the ‘Finalise claim intake’ function.
Believability To improve the believability of the ‘Third Party Details’ data of the ‘Finalise claim intake’ function.
Security To improve the security of the ‘Third Party Details’ data of the ‘Finalise claim intake’ function.
Accessibility To improve the accessibility of the ‘Third Party Details’ data of the ‘Finalise claim intake’ function.
Relevancy To improve the relevancy of the ‘Third Party Details’ data of the ‘Finalise claim intake’ function.
Value-added To increase the value-added of the ‘Third Party Details’ data of the ‘Finalise claim intake’ function.
Completeness To improve the completeness of the ‘‘Third Party Details’ data of the ‘Finalise claim intake’ function.
Amount of Data
To improve the amount of data of the ‘Third Party Details’ data of the ‘Finalise claim intake’ function.
Third Party Vehicle Details - Damage
Accessibility To improve the accessibility of the ‘Third Party Vehicle Details - Damage’ data of the ‘Finalise claim intake’ function.
Relevancy To improve the relevancy of the ‘Third Party Vehicle Details - Damage’ data of the ‘Finalise claim intake’ function.
Security To increase the security of the ‘Third Party Vehicle Details - Damage’ data of the ‘Finalise claim intake’
340
function.
Timeliness To improve the timeliness of the ‘Third Party Vehicle Details - Damage’ data of the ‘Finalise claim intake’ function.
Claim Services Accuracy To improve the accuracy of the ‘Claim Services’ data of the ‘Finalise claim intake’ function.
Objectivity To improve the objectivity of the ‘Claim Services’ data of the ‘Finalise claim intake’ function.
Believability To improve the believability of the ‘Claim Services’ data of the ‘Finalise claim intake’ function.
Reputation To improve the reputation of the ‘Claim Services’ data of the ‘Finalise claim intake’ function.
Accessibility To improve the accessibility of the ‘Claim Services’ data of the ‘Finalise claim intake’ function.
Relevancy To improve the relevancy of the ‘Claim Services’ data of the ‘Finalise claim intake’ function.
Value-added To increase the value-added of the ‘Claim Services’ data of the ‘Finalise claim intake’ function.
Timeliness To increase the timeliness of the ‘Claim Services’ data of the ‘Finalise claim intake’ function.
Completeness To improve the completeness of the ‘‘Claim Services’ data of the ‘Finalise claim intake’ function.
Amount of Data
To improve the amount of data of the ‘Claim Services’ data of the ‘Finalise claim intake’ function.
Assessment Details
Accuracy To improve the accuracy of the ‘Assessment Details’ data of the ‘Finalise claim intake’ function.
Objectivity To improve the objectivity of the ‘Assessment Details’ data of the ‘Finalise claim intake’ function.
Believability To improve the believability of the ‘Assessment Details’ data of the ‘Finalise claim intake’ function.
Reputation To improve the reputation of the ‘Assessment Details’ data of the ‘Finalise claim intake’ function.
Accessibility To improve the accessibility of the ‘Assessment Details’ data of the ‘Finalise claim intake’ function.
Relevancy To improve the relevancy of the ‘Assessment Details’ data of the ‘Finalise claim intake’ function.
Value-added To increase the value-added of the ‘Assessment Details’ data of the ‘Finalise claim intake’ function.
Timeliness To increase the timeliness of the ‘Assessment Details’ data of the ‘Finalise claim intake’ function.
Completeness To improve the completeness of the ‘Assessment Details’ data of the ‘Finalise claim intake’ function.
Amount of Data
To improve the amount of data of the ‘Assessment Details’ data of the ‘Finalise claim intake’ function.
Claim Action Accuracy To improve the accuracy of the ‘Claim Action’ data of the ‘Finalise claim intake’ function.
Objectivity To improve the objectivity of the ‘Claim Action’ data of the ‘Finalise claim intake’ function.
Believability To improve the believability of the ‘Claim Action’ data of the ‘Finalise claim intake’ function.
Reputation To improve the reputation of the ‘Claim Action’ data of the ‘Finalise claim intake’ function.
Accessibility To improve the accessibility of the ‘Claim Action’ data of the ‘Finalise claim intake’ function.
Relevancy To improve the relevancy of the ‘Claim Action’ data
341
of the ‘Finalise claim intake’ function.
Value-added To increase the value-added of the ‘Claim Action’ data of the ‘Finalise claim intake’ function.
Security To increase the security of the ‘Claim Action’ data of the ‘Finalise claim intake’ function.
Timeliness To increase the timeliness of the ‘Claim Action’ data of the ‘Finalise claim intake’ function.
Completeness To improve the completeness of the ‘Claim Action’ data of the ‘Finalise claim intake’ function.
Amount of Data
To improve the amount of data of the ‘Claim Action’ data of the ‘Finalise claim intake’ function.
342
Appendix C.3 Human Resource Softgoal Model
Organisation A – Human Resource Softgoal Model
Functions Resource Quality Characteristics
Soft Goals
F1 - Obtain policy details and validate caller (authorised to lodge)
Claims Processor
Domain Knowledge
To improve the domain knowledge of the Claims Processor performing the ‘Obtain policy details and validate caller’ function.
Communication Skill
To improve the communication skill of the Claims Processor performing the ‘Obtain policy details and validate caller’ function.
F2 - Validate Policy Claims Processor
Domain Knowledge
To improve the domain knowledge of the Claims Processor performing the ‘Validate policy’ function.
Communication Skill
To improve the communication skill of the Claims Processor performing the ‘Validate policy’ function.
F3 - Capture incident details
Claims Processor
Domain Knowledge
To improve the domain knowledge of the Claims Processor performing the ‘Capture incident details’ function.
Experience To increase the experience of the Claims Processor performing the ‘Capture incident details’ function.
Communication Skill
To improve the communication skill of the Claims Processor performing the ‘Capture incident details’ function.
F4 - Validate incident coverage
Claims Processor
Domain Knowledge
To improve the domain knowledge of the Claims Processor performing the ‘Validate incident coverage’ function.
Experience To increase the experience of the Claims Processor performing the ‘Validate incident coverage’ function.
Communication Skill
To improve the communication skill of the Claims Processor performing the ‘Validate incident coverage’ function.
F5 - Assess liability Claims Processor
Domain Knowledge
To improve the domain knowledge of the Claims Processor performing the ‘Assess liability’ function.
Experience To increase the experience of the Claims Processor performing the ‘Assess liability’ function.
Communication Skill
To improve the communication skill of the Claims Processor performing the ‘Assess liability’ function.
F6 - Capture loss and TP details
Claims Processor
Domain Knowledge
To improve the domain knowledge of the Claims Processor performing the ‘Capture loss and TP details’ function.
Experience To increase the experience of the Claims Processor performing the ‘Capture loss and TP details’ function.
Communication Skill
To improve the communication skill of the Claims Processor performing the ‘Capture loss and TP details’ function.
F7 - Assess excess Claims Processor
Domain Knowledge
To improve the domain knowledge of the Claims Processor performing the ‘Assess excess’ function.
Experience To increase the experience of the Claims Processor
343
performing the ‘Assess excess’ function.
Communication Skill
To improve the communication skill of the Claims Processor performing the ‘Assess excess’ function.
F8 - Assess pathing Claims Processor
Domain Knowledge
To improve the domain knowledge of the Claims Processor performing the ‘Assess pathing’ function.
Communication Skill
To improve the communication skill of the Claims Processor performing the ‘Assess pathing’ function.
F9 - Action hire car and towing (as appropriate)
Claims Processor
Domain Knowledge
To improve the domain knowledge of the Claims Processor performing the ‘Action hire car and towing’ function.
Communication Skill
To improve the communication skill of the Claims Processor performing the ‘Action hire car and towing’ function.
F11 - Inform customer of next steps
Claims Processor
Domain Knowledge
To improve the domain knowledge of the Claims Processor performing the ‘Inform Customer of next steps’ function.
Communication Skill
To improve the communication skill of the Claims Processor performing the ‘Inform Customer of next steps’ function.
F12 - Finalise claim intake
N/A N/A N/A
344
Appendix C.4 Non-Human Resource Softgoal Model
Organisation A – Non-Human Resource Softgoal Model
Functions Resource Quality Characteristics
Soft Goals
F1 - Obtain policy details and validate caller (authorised to lodge)
System A
Suitability To improve the suitability of System A performing the ‘Obtain policy details and validate caller’ function.
System A
Reliability To improve the reliability of System A performing the ‘Obtain policy details and validate caller’ function.
System A
Productivity To increase the productivity of System A performing the ‘Obtain policy details and validate caller’ function.
F2 - Validate Policy System A
Suitability To improve the suitability of System A performing the ‘Validate policy’ function.
System A Reliability To improve the reliability of System A performing the ‘Validate policy’ function.
System A Productivity To increase the productivity of System A performing the ‘Validate policy’ function.
F3 - Capture incident details
System A Suitability To improve the suitability of System A performing the ‘Capture incident details’ function.
System A Understandability To improve the understandability of System A performing the ‘Capture incident details’ function.
System A Productivity To increase the productivity of System A performing the ‘Capture incident details’ function.
F4 - Validate incident coverage
System A Accuracy To improve the accuracy of System A performing the ‘Validate incident coverage’ function.
System A Reliability To improve the reliability of System A performing the ‘Validate incident coverage’ function.
System A
Understandability To improve the understandability of System A performing the ‘Validate incident coverage’ function.
F5 - Assess liability System A Accuracy To improve the accuracy of System A performing the ‘Assess liability’ function.
System A Reliability To improve the reliability of System A performing the ‘Assess liability’ function.
System A Robustness To improve the robustness of System A performing the ‘Assess liability’ function.
F6 - Capture loss and TP details
System A
Suitability To improve the suitability of System A performing the ‘Capture loss and TP details’ function.
System A
Understandability To improve the understandability of System A performing the ‘Capture loss and TP details’ function.
System A Productivity To increase the productivity of System A performing the ‘Capture loss and TP details’
345
function.
F7 - Assess excess System A Accuracy To improve the accuracy of System A performing the ‘Assess excess’ function.
System A Reliability To improve the reliability of System A performing the ‘Assess excess’ function.
System A Robustness To improve the robustness of System A performing the ‘Assess excess’ function.
F8 - Assess pathing System A Accuracy To improve the accuracy of System A performing the ‘Assess pathing’ function.
System A Reliability To improve the reliability of System A performing the ‘Assess pathing’ function.
System A Productivity To increase the productivity of System A performing the ‘Assess pathing’ function.
F9 - Action hire car and towing (as appropriate)
System A Suitability To improve the suitability of System A performing the ‘Action hire car and towing’ function.
System A
Understandability To improve the understandability of System A performing the ‘Action hire car and towing’ function.
System A Learnability To improve the learnability of System A performing the ‘Action hire car and towing’ function.
F10 - Add authorised parties (as appropriate)
System A
Suitability To improve the suitability of System A performing the ‘Add authorised parties’ function.
System A Security To improve the security of System A performing the ‘Add authorised parties’ function.
System A
Understandability To improve the understandability of System A performing the ‘Add authorised parties’ function.
F11 - Inform customer of next steps
System A
Suitability To improve the suitability of System A performing the ‘Inform customer of next steps’ function.
System A Accuracy To improve the accuracy of System A performing the ‘Inform customer of next steps’ function.
System A
Understandability To improve the understandability of System A performing the ‘Inform customer of next steps’ function.
F12 - Finalise claim intake
System A Accuracy To improve the accuracy of System A performing the ‘Finalise claim intake’ function.
System A Reliability To improve the reliability of System A performing the ‘Finalise claim intake’ function.
System A Effectiveness To improve the effectiveness of System A performing the ‘Finalise claim intake’ function.
346
Appendix C.5 Softgoal Correlation Model
Organisation A – Softgoal Correlation Model
Functions Input Output Function
Correlated Soft Goal
F12 - Finalise claim intake Incident Details F3 To improve the suitability of the ‘Obtain policy details and validate caller’ function.
To improve the reliability of the ‘Obtain policy details and validate caller’ function. To increase the productivity of the ‘Obtain policy details and validate caller’ function.
Third Party Details F3 To improve the suitability of the ‘Validate policy’ function. To improve the reliability of the ‘Validate policy’ function.
To increase the productivity of the ‘Validate policy’ function. Third Party Vehicle Details -
Damage F3 To improve the suitability of the ‘Validate policy’ function.
To improve the reliability of the ‘Validate policy’ function.
To increase the productivity of the ‘Validate policy’ function. Claim Services F3 To improve the suitability of the ‘Validate policy’ function.
To improve the reliability of the ‘Validate policy’ function. To increase the productivity of the ‘Validate policy’ function. F9 To improve the suitability of the ‘Action hire car and towing’ function. To improve the understandability of the ‘Action hire car and towing’ function.
To improve the learnability of the ‘Action hire car and towing’ function. Assessment Details F3 To improve the suitability of the ‘Validate policy’ function.
To improve the reliability of the ‘Validate policy’ function. To increase the productivity of the ‘Validate policy’ function. F9 To improve the suitability of the ‘Action hire car and towing’ function. To improve the understandability of the ‘Action hire car and towing’ function.
To improve the learnability of the ‘Action hire car and towing’ function. F8 To improve the accuracy of the ‘Assess pathing’ function.
347
To improve the reliability of the ‘Assess pathing’ function. To increase the productivity of the ‘Assess pathing’ function.
F11 - Inform customer of next steps Claim Services F9 To improve the suitability of the ‘Action hire car and towing’ function. To improve the understandability of the ‘Action hire car and towing’ function.
To improve the learnability of the ‘Action hire car and towing’ function.
Assessment Details F9 To improve the suitability of the ‘Action hire car and towing’ function. To improve the understandability of the ‘Action hire car and towing’ function.
To improve the learnability of the ‘Action hire car and towing’ function. F8 To improve the accuracy of the ‘Assess pathing’ function.
To improve the reliability of the ‘Assess pathing’ function. To increase the productivity of the ‘Assess pathing’ function.
F9 - Action hire car and towing (as appropriate)
Coverage and Policy Extras F2 To improve the suitability of the ‘Validate policy’ function.
To improve the reliability of the ‘Validate policy’ function. To increase the productivity of the ‘Validate policy’ function.
Customer Vehicle Details - Damage
F2 To improve the suitability of the ‘Validate policy’ function.
To improve the reliability of the ‘Validate policy’ function.
To increase the productivity of the ‘Validate policy’ function. F8 - Assess pathing Incident Details F3 To improve the suitability of the ‘Validate policy’ function.
To improve the reliability of the ‘Validate policy’ function. To increase the productivity of the ‘Validate policy’ function. Customer Vehicle Details -
Damage F3 To improve the suitability of the ‘Validate policy’ function.
To improve the reliability of the ‘Validate policy’ function. To increase the productivity of the ‘Validate policy’ function. F7 - Assess excess Coverage and Policy Extras F2 To improve the suitability of the ‘Validate policy’ function. To improve the reliability of the ‘Validate policy’ function.
To increase the productivity of the ‘Validate policy’ function. Vehicle Information F2 To improve the suitability of the ‘Validate policy’ function.
To improve the reliability of the ‘Validate policy’ function.
348
To increase the productivity of the ‘Validate policy’ function. Incident Details F2 To improve the suitability of the ‘Validate policy’ function.
To improve the reliability of the ‘Validate policy’ function. To increase the productivity of the ‘Validate policy’ function.
F3 To improve the suitability of the ‘Validate policy’ function. To improve the reliability of the ‘Validate policy’ function.
To increase the productivity of the ‘Validate policy’ function. F6 - Capture loss and TP details Vehicle Identification F2 To improve the suitability of the ‘Validate policy’ function.
To improve the reliability of the ‘Validate policy’ function. To increase the productivity of the ‘Validate policy’ function.
Driver Details F2 To improve the suitability of the ‘Validate policy’ function. To improve the reliability of the ‘Validate policy’ function.
To increase the productivity of the ‘Validate policy’ function. Customer Vehicle Details -
Damage F2 To improve the suitability of the ‘Validate policy’ function.
To improve the reliability of the ‘Validate policy’ function. To increase the productivity of the ‘Validate policy’ function.
Customer Personal Property F2 To improve the suitability of the ‘Validate policy’ function. To improve the reliability of the ‘Validate policy’ function.
To increase the productivity of the ‘Validate policy’ function. Third Party Details F2 To improve the suitability of the ‘Validate policy’ function.
To improve the reliability of the ‘Validate policy’ function. To increase the productivity of the ‘Validate policy’ function.
Other Party Details F2 To improve the suitability of the ‘Validate policy’ function. To improve the reliability of the ‘Validate policy’ function.
To increase the productivity of the ‘Validate policy’ function. F5 - Assess liability Incident Details F3 To improve the suitability of the ‘Validate policy’ function.
To improve the reliability of the ‘Validate policy’ function. To increase the productivity of the ‘Validate policy’ function. F4 - Validate incident coverage Coverage and Policy Extras F2 To improve the suitability of the ‘Validate policy’ function.
349
To improve the reliability of the ‘Validate policy’ function. To increase the productivity of the ‘Validate policy’ function.
F2 - Validate Policy Policy Identification F1 To improve the suitability of the ‘Obtain policy details and validate caller’ function. To improve the reliability of the ‘Obtain policy details and validate caller’ function.
To increase the productivity of the ‘Obtain policy details and validate caller’ function.
350
Appendix C.6 Function Measurement Model
Organisation A – Function Measurement Model
Functions Quality Characteristics
Soft Goals Question Metric Threshold Value
F1 - Obtain policy details and validate caller (authorised to lodge)
Suitability To improve the suitability of the ‘Obtain policy details and validate caller’ function.
What is the current suitability of the ‘Obtain policy details and validate caller’ function? What is the deviation of the current suitability from the desired one?
Are policy details obtained?
Yes
Is caller validated? Yes
Reliability To improve the reliability of the ‘Obtain policy details and validate caller’ function.
What is the current reliability of the ‘Obtain policy details and validate caller’ function? What is the deviation of the current reliability from the desired one?
Percentage uptime (%) > 99.995%
Productivity To ensure the function is completed in an adequate time
What is the current productivity of the ‘Obtain policy details and validate caller’ function? What is the deviation of the current productivity from the desired one?
Task Time < 2 minutes
F2 - Validate Policy Suitability To improve the suitability of the ‘Validate policy’ function.
What is the current suitability of the ‘Validate Policy’ function? What is the deviation of the current suitability from the desired one?
Is policy validated? Yes
Reliability To improve the reliability of the ‘Validate policy’
What is the current reliability of the ‘Validate Policy’ function?
Percentage uptime (%) > 99.995%
351
function. What is the deviation of the current reliability from the desired one?
Productivity To increase the productivity of the ‘Validate policy’ function.
What is the current productivity of the ‘Validate Policy’ function? What is the deviation of the current productivity from the desired one?
Task Time < 2 minutes
F3 - Capture incident details
Suitability To improve the suitability of the ‘Capture incident details’ function.
What is the current suitability of the ‘Capture incident details’ function? What is the deviation of the current suitability from the desired one?
Were incident details captured?
Yes
Understandability To improve the understandability of the ‘Capture incident details’ function.
What is the current understandability of the ‘Capture incident details’ function? What is the deviation of the current understandability from the desired one?
Is a ‘User Guide’ available?
Yes
Is ‘Help Documentation’ available?
Yes
Productivity To increase the productivity of the ‘Capture incident details’ function.
What is the current productivity of the ‘Capture incident details’ function? What is the deviation of the current productivity from the desired one?
Task Time < 5 minutes
F4 - Validate incident coverage
Accuracy To improve the accuracy of ‘Validate incident coverage’ function.
What is the current accuracy of the ‘Validate incident coverage’ function? What is the deviation of the current accuracy from the desired one?
Subjective evaluation n/a
Reliability To improve the reliability of ‘Validate incident coverage’ function.
What is the current reliability of the ‘Validate incident coverage’ function? What is the deviation of the current reliability from the desired one?
Percentage uptime (%) > 99.995%
Understandability To improve the What is the current Is a ‘User Guide’ Yes
352
understandability of the ‘Validate incident coverage’ function.
understandability of the ‘Validate incident coverage’ function? What is the deviation of the current understandability from the desired one?
available?
Is ‘Help Documentation’ available?
Yes
F5 - Assess liability Accuracy To improve the accuracy of the ‘Assess liability’ function.
What is the current accuracy of the ‘Assess Liability’ function? What is the deviation of the current accuracy from the desired one?
Subjective evaluation n/a
Reliability To improve the reliability of the ‘Assess liability’ function.
What is the current reliability of the ‘Assess Liability’ function? What is the deviation of the current reliability from the desired one?
Percentage uptime (%) > 99.995 %
Robustness To improve the robustness of the ‘Assess liability’ function.
What is the current robustness of the ‘Assess Liability’ function? What is the deviation of the current robustness from the desired one?
Length of maximum tolerable outage (minutes)
< 10 minutes
Mean time between failures
> 20 days
F6 - Capture loss and TP details
Suitability To improve the suitability of the ‘Capture loss and TP details’ function.
What is the current suitability of the ‘Capture loss and TP details’ function? What is the deviation of the current suitability from the desired one?
Were loss and TP details captured?
Yes
Understandability To improve the understandability of the ‘Capture loss and TP details’ function.
What is the current understandability of the ‘Capture loss and TP detail’ function? What is the deviation of the current understandability from the desired one?
Is a ‘User Guide’ available?
Yes
Is ‘Help Documentation’ Yes
353
available?
Productivity To increase the productivity of the ‘Capture loss and TP details’ function.
What is the current productivity of the ‘Capture loss and TP detail’ function? What is the deviation of the current productivity from the desired one?
Task Time < 3 minutes
F7 - Assess excess Accuracy To improve the accuracy of the ‘Assess excess’ function.
What is the current accuracy of the ‘Assess excess’ function? What is the deviation of the current accuracy from the desired one?
Subjective evaluation n/a
Reliability To improve the reliability of the ‘Assess excess’ function.
What is the current reliability of the ‘Assess excess’ function? What is the deviation of the current reliability from the desired one?
Percentage uptime (%) > 99.995%
Robustness To improve the robustness of the ‘Assess excess’ function.
What is the current robustness of the ‘Assess excess’ function? What is the deviation of the current robustness from the desired one?
Length of maximum tolerable outage (minutes)
< 10 minutes
Mean time between failures
> 20 days
F8 - Assess pathing Accuracy To improve the accuracy of the ‘Assess pathing’ function.
What is the current accuracy of the ‘Assess pathing’ function? What is the deviation of the current accuracy from the desired one?
Subjective evaluation n/a
Reliability To improve the reliability of the ‘Assess pathing’ function.
What is the current reliability of the ‘Assess pathing’ function? What is the deviation of the current reliability from the desired one?
Percentage uptime (%) > 99.995%
Productivity To increase the productivity of the ‘Assess pathing’ function.
What is the current productivity of the ‘Assess pathing’ function? What is the deviation
Task Time < 2 minutes
354
of the current productivity from the desired one?
F9 - Action hire car and towing (as appropriate)
Suitability To improve the suitability of the ‘Action hire car and towing’ function.
What is the current suitability of the ‘Action hire car and towing’ function? What is the deviation of the current suitability from the desired one?
Was hire car and towing actioned (if required)?
Yes
Understandability To improve the understandability of the ‘Action hire car and towing’ function.
What is the current understandability of the ‘Action hire car and towing’ function? What is the deviation of the current understandability from the desired one?
Is a ‘User Guide’ available?
Yes
Is ‘Help Documentation’ available?
Yes
Learnability To improve the learnability of the ‘Action hire car and towing’ function.
What is the current learnability of the ‘Action hire car and towing’ function? What is the deviation of the current learnability from the desired one?
Help Frequency < 2 per week
Is ‘Help Documentation’ available?
Yes
Is ‘Help Documentation’ easily accessible?
Yes
F10 - Add authorised parties (as appropriate)
Suitability To improve the suitability of the ‘Add authorised parties’ function.
What is the current suitability of the ‘Add authorised parties’ function? What is the deviation of the current suitability from the desired one?
Were authorised parties added (if required)?
Yes
Security To improve the security of the ‘Add authorised parties’ function.
What is the current security of the ‘Add authorised parties’ function? What is the deviation of the current security from the desired one?
Authenticated Access Yes
Authorised Access Yes
355
Audit Trail Yes
Understandability To improve the understandability of the ‘Add authorised parties’ function.
What is the current understandability of the ‘Add authorised parties’ function? What is the deviation of the current understandability from the desired one?
Is a ‘User Guide’ available?
Yes
Is ‘Help Documentation’ available?
Yes
F11 - Inform customer of next steps
Suitability To improve the suitability of the ‘Inform customer of next steps’ function.
What is the current suitability of the ‘Inform customer of next steps’ function? What is the deviation of the current suitability from the desired one?
Was the customer informed of the next steps?
Yes
Accuracy To improve the accuracy of the ‘Inform customer of next steps’ function.
What is the current accuracy of the ‘Inform customer of next steps’ function? What is the deviation of the current accuracy from the desired one?
Subjective evaluation n/a
Understandability To improve the understandability of the ‘Inform customer of next steps’ function.
What is the current understandability of the ‘Inform customer of next steps’ function? What is the deviation of the current understandability from the desired one?
Is a ‘User Guide’ available?
Yes
Is ‘Help Documentation’ available?
Yes
F12 - Finalise claim intake
Accuracy To improve the accuracy of the ‘Finalise claim intake’ function.
What is the current accuracy of the ‘Finalise claim intake’ function? What is the deviation of the current accuracy from the desired one?
Subjective evaluation n/a
Reliability To improve the reliability of the ‘Finalise claim intake’ function.
What is the current reliability of the ‘Finalise claim intake’ function? What is the deviation of the current reliability from
Percentage uptime (%) > 99.995%
356
the desired one?
Effectiveness To improve the effectiveness of the ‘Finalise claim intake’ function.
What is the current effectiveness of the ‘Finalise claim intake’ function? What is the deviation of the current effectiveness from the desired one?
Subjective evaluation n/a
357
Appendix C.7 Input & Output Measurement Model
Organisation A – Input & Output Measurement Model
Function Input/Output Data
Quality Characteristics
Soft Goals Question Metric Threshold Value
F1 - Obtain policy details and validate caller (authorised to lodge)
Customer Identification
Accuracy To improve the accuracy of the ‘Customer Identification’ data of the ‘Obtain policy details and validate caller’ function.
What is the current accuracy of the ‘Customer Identification’ data of the ‘Obtain policy details and validate caller’ function? What is the deviation of the current accuracy from the desired one?
Subjective evaluation
n/a
Objectivity To improve the objectivity of the ‘Customer Identification’ data of the ‘Obtain policy details and validate caller’ function.
What is the current objectivity of the ‘Customer Identification’ data of the ‘Obtain policy details and validate caller’ function? What is the deviation of the current objectivity from the desired one?
Source of Data
=Policyholder
Believability To improve the believability of the ‘Customer Identification’ data of the ‘Obtain policy details and validate caller’ function.
What is the current believability of the ‘Customer Identification’ data of the ‘Obtain policy details and validate caller’ function? What is the deviation of the current believability from the desired one?
Source of Data
=Policyholder
Reputation To improve the reputation of the ‘Customer Identification’ data of the ‘Obtain policy details and validate caller’ function.
What is the current reputation of the ‘Customer Identification’ data of the ‘Obtain policy details and validate caller’ function? What is the deviation of the current reputation from the desired one?
Source of Data
=Policyholder
Relevancy To improve the relevancy of the ‘Customer Identification’ data of the ‘Obtain policy details and validate caller’ function.
What is the current relevancy of the ‘Customer Identification’ data of the ‘Obtain policy details and validate caller’ function? What is the deviation of the current relevancy from the desired one?
Assists in establishing Identity
Yes
358
Timeliness To improve the timeliness of the ‘Customer Identification’ data of the ‘Obtain policy details and validate caller’ function.
What is the current timeliness of the ‘Customer Identification’ data of the ‘Obtain policy details and validate caller’ function? What is the deviation of the current timeliness from the desired one?
Age of Data = Current
Completeness To improve the completeness of the ‘Customer Identification’ data of the ‘Obtain policy details and validate caller’ function.
What is the current completeness of the ‘Customer Identification’ data of the ‘Obtain policy details and validate caller’ function? What is the deviation of the current completeness from the desired one?
All fields present that confirm identification
Yes
Amount of Data
To improve the amount of data of the ‘Customer Identification’ data of the ‘Obtain policy details and validate caller’ function.
What is the current amount of data of the ‘Customer Identification’ data of the ‘Obtain policy details and validate caller’ function? What is the deviation of the current amount of data from the desired one?
Enough data exists to confirm identification
Yes
Accessibility To improve the accessibility of the ‘Customer Identification’ data of the ‘Obtain policy details and validate caller’ function.
What is the current accessibility of the ‘Customer Identification’ data of the ‘Obtain policy details and validate caller’ function? What is the deviation of the current accessibility from the desired one?
Customer can provide data
Yes
Customer Products
Accuracy To improve the accuracy of the ‘Customer Products’ data of the ‘Obtain policy details and validate caller’ function.
What is the current accuracy of the ‘Customer Products’ data of the ‘Obtain policy details and validate caller’ function? What is the deviation of the current accuracy from the desired one?
Subjective evaluation
n/a
Objectivity To improve the objectivity of the ‘Customer Products’ data of the ‘Obtain policy details and validate caller’ function.
What is the current objectivity of the ‘Customer Products’ data of the ‘Obtain policy details and validate caller’ function? What is the deviation of the current objectivity from the desired one?
Source of data
= System A
Believability To improve the believability of the ‘Customer Products’ data
What is the current believability of the ‘Customer Products’ data of the ‘Obtain policy details and validate caller’
Source of Data
= System A
359
of the ‘Obtain policy details and validate caller’ function.
function? What is the deviation of the current believability from the desired one?
Reputation To improve the reputation of the ‘Customer Products’ data of the ‘Obtain policy details and validate caller’ function.
What is the current reputation of the ‘Customer Products’ data of the ‘Obtain policy details and validate caller’ function? What is the deviation of the current reputation from the desired one?
Source of data
= System A
Relevancy To improve the relevancy of the ‘Customer Products’ data of the ‘Obtain policy details and validate caller’ function.
What is the current relevancy of the ‘Customer Products’ data of the ‘Obtain policy details and validate caller’ function? What is the deviation of the current relevancy from the desired one?
Can determine if valid policy exists
Yes
Security To increase the security of the ‘Customer Products’ data of the ‘Obtain policy details and validate caller’ function.
What is the current security of the ‘Customer Products’ data of the ‘Obtain policy details and validate caller’ function? What is the deviation of the current security from the desired one?
Data is available to authorised users only
Yes
Timeliness To improve the timeliness of the ‘Customer Products’ data of the ‘Obtain policy details and validate caller’ function.
What is the current timeliness of the ‘Customer Products’ data of the ‘Obtain policy details and validate caller’ function? What is the deviation of the current timeliness from the desired one?
Data is current
Yes
Completeness To improve the completeness of the ‘Customer Products’ data of the ‘Obtain policy details and validate caller’ function.
What is the current completeness of the ‘Customer Products’ data of the ‘Obtain policy details and validate caller’ function? What is the deviation of the current completeness from the desired one?
All fields present to determine if valid policy exists
Yes
Amount of Data
To improve the amount of data of the ‘Customer Products’ data of the ‘Obtain policy details and validate caller’ function.
What is the current amount of data of the ‘Customer Products’ data of the ‘Obtain policy details and validate caller’ function? What is the deviation of the current amount of data from the desired one?
Enough data exists to determine if valid policy exists
Yes
360
Accessibility To improve the accessibility of the ‘Customer Products’ data of the ‘Obtain policy details and validate caller’ function.
What is the current accessibility of the ‘Customer Products’ data of the ‘Obtain policy details and validate caller’ function? What is the deviation of the current accessibility from the desired one?
Location of Data
= System A
Policy Identification
Accuracy To improve the accessibility of the ‘Policy Identification’ data of the ‘Obtain policy details and validate caller’ function.
What is the current accuracy of the ‘Policy Identification’ data of the ‘Obtain policy details and validate caller’ function? What is the deviation of the current accuracy from the desired one?
Subjective evaluation
n/a
Objectivity To improve the objectivity of the ‘Policy Identification’ data of the ‘Obtain policy details and validate caller’ function.
What is the current objectivity of the ‘Policy Identification’ data of the ‘Obtain policy details and validate caller’ function? What is the deviation of the current objectivity from the desired one?
Source of data
= System A
Believability To improve the believability of the ‘Policy Identification’ data of the ‘Obtain policy details and validate caller’ function.
What is the current believability of the ‘Policy Identification’ data of the ‘Obtain policy details and validate caller’ function? What is the deviation of the current believability from the desired one?
Source of data
= System A
Reputation To improve the reputation of the ‘Policy Identification’ data of the ‘Obtain policy details and validate caller’ function.
What is the current reputation of the ‘Policy Identification’ data of the ‘Obtain policy details and validate caller’ function? What is the deviation of the current reputation from the desired one?
Source of data
= System A
Relevancy To improve the relevancy of the ‘Policy Identification’ data of the ‘Obtain policy details and validate caller’ function.
What is the current relevancy of the ‘Policy Identification’ data of the ‘Obtain policy details and validate caller’ function? What is the deviation of the current relevancy from the desired one?
Assists in determining appropriate policy
Yes
Security To increase the security of the ‘Policy
What is the current security of the ‘Policy Identification’ data of the ‘Obtain policy
User can access data
Yes
361
Identification’ data of the ‘Obtain policy details and validate caller’ function.
details and validate caller’ function? What is the deviation of the current security from the desired one?
Timeliness To improve the timeliness of the ‘Policy Identification’ data of the ‘Obtain policy details and validate caller’ function.
What is the current timeliness of the ‘Policy Identification’ data of the ‘Obtain policy details and validate caller’ function? What is the deviation of the current timeliness from the desired one?
Age of Data < 1 month
Completeness To improve the completeness of the ‘Policy Identification’ data of the ‘Obtain policy details and validate caller’ function.
What is the current completeness of the ‘Policy Identification’ data of the ‘Obtain policy details and validate caller’ function? What is the deviation of the current completeness from the desired one?
All fields present that confirm identification
Yes
Amount of Data
To improve the amount of data of the ‘Policy Identification’ data of the ‘Obtain policy details and validate caller’ function.
What is the current amount of data of the ‘Policy Identification’ data of the ‘Obtain policy details and validate caller’ function? What is the deviation of the current amount of data from the desired one?
Enough data exists to confirm identification
Yes
Accessibility To improve the accessibility of the ‘Policy Identification’ data of the ‘Obtain policy details and validate caller’ function.
What is the current accessibility of the ‘Policy Identification’ data of the ‘Obtain policy details and validate caller’ function? What is the deviation of the current accessibility from the desired one?
Location of Data
= System A
F2 - Validate Policy
Policy Identification
Accuracy To improve the accuracy of the ‘Policy Identification’ data of the ‘Validate policy’ function.
What is the current accuracy of the ‘Policy Identification’ data of the ‘Validate policy’ function? What is the deviation of the current accuracy from the desired one?
Subjective evaluation
n/a
Objectivity To improve the objectivity of the ‘Policy Identification’ data of the ‘Validate policy’ function.
What is the current objectivity of the ‘Policy Identification’ data of the ‘Validate policy’ function? What is the deviation of the current objectivity from the desired one?
Source of Data
= System A
362
Believability To improve the believability of the ‘Policy Identification’ data of the ‘Validate policy’ function.
What is the current believability of the ‘Policy Identification’ data of the ‘Validate policy’ function? What is the deviation of the current believability from the desired one?
Source of Data
= System A
Reputation To improve the reputation of the ‘Policy Identification’ data of the ‘Validate policy’ function.
What is the current reputation of the ‘Policy Identification’ data of the ‘Validate policy’ function? What is the deviation of the current reputation from the desired one?
Source of Data
= System A
Relevancy To improve the relevancy of the ‘Policy Identification’ data of the ‘Validate policy’ function.
What is the current relevancy of the ‘Policy Identification’ data of the ‘Validate policy’ function? What is the deviation of the current relevancy from the desired one?
Assists in determining appropriate policy
Yes
Security To increase the security of the ‘Policy Identification’ data of the ‘Validate policy’ function.
What is the current security of the ‘Policy Identification’ data of the ‘Validate policy’ function? What is the deviation of the current security from the desired one?
User can access data
Yes
Timeliness To improve the timeliness of the ‘Policy Identification’ data of the ‘Validate policy’ function.
What is the current timeliness of the ‘Policy Identification’ data of the ‘Validate policy’ function? What is the deviation of the current timeliness from the desired one?
Age of Data < 1 month
Completeness To improve the completeness of the ‘Policy Identification’ data of the ‘Validate policy’ function.
What is the current completeness of the ‘Policy Identification’ data of the ‘Validate policy’ function? What is the deviation of the current completeness from the desired one?
All fields present that confirm identification
Yes
Amount of Data
To improve the amount of data of the ‘Policy Identification’ data of the ‘Validate policy’ function.
What is the current amount of data of the ‘Policy Identification’ data of the ‘Validate policy’ function? What is the deviation of the current amount of data from the desired one?
Enough data exists to confirm identification
Yes
Accessibility To improve the accessibility of the ‘Policy
What is the current accessibility of the ‘Policy Identification’ data of the ‘Validate
Location of Data
= System A
363
Identification’ data of the ‘Validate policy’ function.
policy’ function? What is the deviation of the current accessibility from the desired one?
Coverage and Policy Extras
Accuracy To improve the accuracy of the ‘Coverage and Policy Extras’ data of the ‘Validate policy’ function.
What is the current accuracy of the ‘Coverage and Policy Extras’ data of the ‘Validate policy’ function? What is the deviation of the current accuracy from the desired one?
Subjective evaluation
n/a
Objectivity To improve the objectivity of the ‘Coverage and Policy Extras’ data of the ‘Validate policy’ function.
What is the current objectivity of the ‘Coverage and Policy Extras’ data of the ‘Validate policy’ function? What is the deviation of the current objectivity from the desired one?
Source of data
= System A
Believability To improve the believability of the ‘Coverage and Policy Extras’ data of the ‘Validate policy’ function.
What is the current believability of the ‘Coverage and Policy Extras’ data of the ‘Validate policy’ function? What is the deviation of the current believability from the desired one?
Source of data
= System A
Reputation To improve the reputation of the ‘Coverage and Policy Extras’ data of the ‘Validate policy’ function.
What is the current reputation of the ‘Coverage and Policy Extras’ data of the ‘Validate policy’ function? What is the deviation of the current reputation from the desired one?
Source of data
= System A
Relevancy To improve the relevancy of the ‘Coverage and Policy Extras’ data of the ‘Validate policy’ function.
What is the current relevancy of the ‘Coverage and Policy Extras’ data of the ‘Validate policy’ function? What is the deviation of the current relevancy from the desired one?
Subjective evaluation
n/a
Security To increase the security of the ‘Coverage and Policy Extras’ data of the ‘Validate policy’ function.
What is the current security of the ‘Coverage and Policy Extras’ data of the ‘Validate policy’ function? What is the deviation of the current security from the desired one?
User can access data
Yes
364
Timeliness To improve the timeliness of the ‘Coverage and Policy Extras’ data of the ‘Validate policy’ function.
What is the current timeliness of the ‘Coverage and Policy Extras’ data of the ‘Validate policy’ function? What is the deviation of the current timeliness from the desired one?
Age of Data > 1 month
Completeness To improve the completeness of the ‘Coverage and Policy Extras’ data of the ‘Validate policy’ function.
What is the current completeness of the ‘Coverage and Policy Extras’ data of the ‘Validate policy’ function? What is the deviation of the current completeness from the desired one?
All fields present that confirm policy coverage
Yes
Amount of Data
To improve the amount of data of the ‘Coverage and Policy Extras’ data of the ‘Validate policy’ function.
What is the current amount of data of the ‘Coverage and Policy Extras’ data of the ‘Validate policy’ function? What is the deviation of the current amount of data from the desired one?
Enough data exists to confirm policy coverage
Yes
Accessibility To improve the accessibility of the ‘Coverage and Policy Extras’ data of the ‘Validate policy’ function.
What is the current accessibility of the ‘Coverage and Policy Extras’ data of the ‘Validate policy’ function? What is the deviation of the current accessibility from the desired one?
Location of Data
= System A
Vehicle Identification
Reputation To improve the reputation of the ‘Vehicle Identification’ data of the ‘Validate policy’ function.
What is the current reputation of the ‘Vehicle Identification’ data of the ‘Validate policy’ function? What is the deviation of the current reputation from the desired one?
Source of data
=Policyholder
Relevancy To improve the relevancy of the ‘Vehicle Identification’ data of the ‘Validate policy’ function.
What is the current relevancy of the ‘Vehicle Identification’ data of the ‘Validate policy’ function? What is the deviation of the current relevancy from the desired one?
Describes vehicle identity
Yes
Timeliness To improve the timeliness of the ‘Vehicle Identification’ data of the ‘Validate policy’ function.
What is the current timeliness of the ‘Vehicle Identification’ data of the ‘Validate policy’ function? What is the deviation of the current timeliness from the desired one?
Age of Data = current
365
Completeness To improve the completeness of the ‘Vehicle Identification’ data of the ‘Validate policy’ function.
What is the current completeness of the ‘Vehicle Identification’ data of the ‘Validate policy’ function? What is the deviation of the current completeness from the desired one?
All fields present that confirm identification
Yes
Amount of Data
To improve the amount of data of the ‘Vehicle Identification’ data of the ‘Validate policy’ function.
What is the current amount of data of the ‘Vehicle Identification’ data of the ‘Validate policy’ function? What is the deviation of the current amount of data from the desired one?
Enough data exists to confirm identification
Yes
F3 - Capture incident details
Incident Details Accuracy To improve the accuracy of the ‘Incident Details’ data of the ‘Capture incident details’ function.
What is the current accuracy of the ‘Incident Details’ data of the ‘Capture incident details’ function? What is the deviation of the current accuracy from the desired one?
Subjective evaluation
n/a
Objectivity To improve the objectivity of the ‘Incident Details’ data of the ‘Capture incident details’ function.
What is the current objectivity of the ‘Incident Details’ data of the ‘Capture incident details’ function? What is the deviation of the current objectivity from the desired one?
Caller witnessed incident?
Yes
Corroborating witnesses exist?
Yes
Believability To improve the believability of the ‘Incident Details’ data of the ‘Capture incident details’ function.
What is the current believability of the ‘Incident Details’ data of the ‘Capture incident details’ function? What is the deviation of the current believability from the desired one?
Caller witnessed incident?
Yes
Corroborating witnesses exist?
Yes
Reputation To improve the reputation of the ‘Incident Details’ data of the ‘Capture incident details’ function.
What is the current reputation of the ‘Incident Details’ data of the ‘Capture incident details’ function? What is the deviation of the current reputation from the desired one?
Caller witnessed incident?
Yes
Corroborating Yes
366
witnesses exist?
Relevancy To improve the relevancy of the ‘Incident Details’ data of the ‘Capture incident details’ function.
What is the current relevancy of the ‘Incident Details’ data of the ‘Capture incident details’ function? What is the deviation of the current relevancy from the desired one?
Motor vehicle incident related
Yes
Value-added To increase the value-added of the ‘Incident Details’ data of the ‘Capture incident details’ function.
What is the current added value of the ‘Incident Details’ data of the ‘Capture incident details’ function? What is the deviation of the current added value from the desired one?
Incident detail is descriptive
Yes
Security To increase the security of the ‘Incident Details’ data of the ‘Capture incident details’ function.
What is the current security of the ‘Incident Details’ data of the ‘Capture incident details’ function? What is the deviation of the current security from the desired one?
Is audited? Yes
Timeliness To improve the timeliness of the ‘Incident Details’ data of the ‘Capture incident details’ function.
What is the current timeliness of the ‘Incident Details’ data of the ‘Capture incident details’ function? What is the deviation of the current timeliness from the desired one?
Time since incident
< 1 month
Completeness To improve the completeness of the ‘Incident Details’ data of the ‘Capture incident details’ function.
What is the current completeness of the ‘Incident Details’ data of the ‘Capture incident details’ function? What is the deviation of the current completeness from the desired one?
All mandatory details exist
Yes
Amount of Data
To improve the amount of data of the ‘Incident Details’ data of the ‘Capture incident details’ function.
What is the current amount of data of the ‘Incident Details’ data of the ‘Capture incident details’ function? What is the deviation of the current amount of data from the desired one?
Enough data exists to define incident
Yes
Accessibility To improve the accessibility of the ‘Incident Details’ data of the ‘Capture incident details’ function.
What is the current accessibility of the ‘Incident Details’ data of the ‘Capture incident details’ function? What is the deviation of the current accessibility from the desired one?
Location of Data
= System A
367
F4 - Validate incident coverage
Coverage and Policy Extras
Accuracy To improve the accuracy of the ‘Coverage and Policy Extras’ data of the ‘Validate incident coverage’ function.
What is the current accuracy of the ‘Coverage and Policy Extras’ data of the ‘Validate incident coverage’ function? What is the deviation of the current accuracy from the desired one?
Subjective evaluation
n/a
Objectivity To improve the objectivity of the ‘Coverage and Policy Extras’ data of the ‘Validate incident coverage’ function.
What is the current objectivity of the ‘Coverage and Policy Extras’ data of the ‘Validate incident coverage’ function? What is the deviation of the current objectivity from the desired one?
Source of Data
= System A
Believability To improve the believability of the ‘Coverage and Policy Extras’ data of the ‘Validate incident coverage’ function.
What is the current believability of the ‘Coverage and Policy Extras’ data of the ‘Validate incident coverage’ function? What is the deviation of the current believability from the desired one?
Source of Data
= System A
Reputation To improve the reputation of the ‘Coverage and Policy Extras’ data of the ‘Validate incident coverage’ function.
What is the current reputation of the ‘Coverage and Policy Extras’ data of the ‘Validate incident coverage’ function? What is the deviation of the current reputation from the desired one?
Source of Data
= System A
Accessibility To improve the accessibility of the ‘Coverage and Policy Extras’ data of the ‘Validate incident coverage’ function.
What is the current accessibility of the ‘Coverage and Policy Extras’ data of the ‘Validate incident coverage’ function? What is the deviation of the current accessibility from the desired one?
Location of Data
= System A
Relevancy To improve the relevancy of the ‘Coverage and Policy Extras’ data of the ‘Validate incident coverage’ function.
What is the current relevancy of the ‘Coverage and Policy Extras’ data of the ‘Validate incident coverage’ function? What is the deviation of the current relevancy from the desired one?
n/a n/a
Security To increase the security of the ‘Coverage and Policy Extras’ data of the
What is the current security of the ‘Coverage and Policy Extras’ data of the ‘Validate incident coverage’ function?
User can access data
Yes
368
‘Validate incident coverage’ function.
What is the deviation of the current security from the desired one?
Completeness To improve the completeness of the ‘Coverage and Policy Extras’ data of the ‘Validate incident coverage’ function.
What is the current completeness of the ‘Coverage and Policy Extras’ data of the ‘Validate incident coverage’ function? What is the deviation of the current completeness from the desired one?
All fields present that confirm policy coverage
Yes
Amount of Data
To improve the amount of data of the ‘Coverage and Policy Extras’ data of the ‘Validate incident coverage’ function.
What is the current amount of data of the ‘Coverage and Policy Extras’ data of the ‘Validate incident coverage’ function? What is the deviation of the current amount of data from the desired one?
Enough data exists to confirm policy coverage
Yes
Timeliness To improve the timeliness of the ‘Coverage and Policy Extras’ data of the ‘Validate incident coverage’ function.
What is the current timeliness of the ‘Coverage and Policy Extras’ data of the ‘Validate incident coverage’ function? What is the deviation of the current timeliness from the desired one?
Age of Data < 1 month
Claim Business Rules
Accuracy To improve the accuracy of the ‘Claim Business Rules’ data of the ‘Validate incident coverage’ function.
What is the current accuracy of the ‘Claim Business Rules’ data of the ‘Validate incident coverage’ function? What is the deviation of the current accuracy from the desired one?
Subjective evaluation
n/a
Objectivity To improve the objectivity of the ‘Claim Business Rules’ data of the ‘Validate incident coverage’ function.
What is the current objectivity of the ‘Claim Business Rules’ data of the ‘Validate incident coverage’ function? What is the deviation of the current objectivity from the desired one?
Source of data
Published policy
Believability To improve the believability of the ‘Claim Business Rules’ data of the ‘Validate incident coverage’ function.
What is the current believability of the ‘Claim Business Rules’ data of the ‘Validate incident coverage’ function? What is the deviation of the current believability from the desired one?
Source of data
Published policy
Reputation To improve the reputation of the ‘Claim
What is the current reputation of the ‘Claim Business Rules’ data of the
Source of data
Published policy
369
Business Rules’ data of the ‘Validate incident coverage’ function.
‘Validate incident coverage’ function? What is the deviation of the current reputation from the desired one?
Accessibility To improve the accessibility of the ‘Claim Business Rules’ data of the ‘Validate incident coverage’ function.
What is the current accessibility of the ‘Claim Business Rules’ data of the ‘Validate incident coverage’ function? What is the deviation of the current accessibility from the desired one?
Storage method
= electronic
Relevancy To improve the relevancy of the ‘Claim Business Rules’ data of the ‘Validate incident coverage’ function.
What is the current relevancy of the ‘Claim Business Rules’ data of the ‘Validate incident coverage’ function? What is the deviation of the current relevancy from the desired one?
Related to appropriate policy
Yes
Value-added To increase the value-added of the ‘Claim Business Rules’ data of the ‘Validate incident coverage’ function.
What is the current added value of the ‘Claim Business Rules’ data of the ‘Validate incident coverage’ function? What is the deviation of the current added value from the desired one?
Business rules are descriptive
Yes
Security To increase the security of the ‘Claim Business Rules’ data of the ‘Validate incident coverage’ function.
What is the current security of the ‘Claim Business Rules’ data of the ‘Validate incident coverage’ function? What is the deviation of the current security from the desired one?
User has access
Yes
Completeness To improve the completeness of the ‘Claim Business Rules’ data of the ‘Validate incident coverage’ function.
What is the current completeness of the ‘Claim Business Rules’ data of the ‘Validate incident coverage’ function? What is the deviation of the current completeness from the desired one?
Rules describe all possible cases
Yes
Amount of Data
To improve the amount of data of the ‘Claim Business Rules’ data of the ‘Validate incident coverage’ function.
What is the current amount of data of the ‘Claim Business Rules’ data of the ‘Validate incident coverage’ function? What is the deviation of the current amount of data from the desired one?
Enough information exists to validate incident coverage
Yes
Timeliness To improve the timeliness of the ‘Claim
What is the current timeliness of the ‘Claim Business Rules’ data of the
Age of Data = Current
370
Business Rules’ data of the ‘Validate incident coverage’ function.
‘Validate incident coverage’ function? What is the deviation of the current timeliness from the desired one?
F5 - Assess liability
Incident Details Accuracy To improve the accuracy of the ‘Incident Details’ data of the ‘Assess liability’ function.
What is the current accuracy of the ‘Incident Details’ data of the ‘Assess Liability’ function? What is the deviation of the current accuracy from the desired one?
Subjective evaluation
n/a
Objectivity To improve the objectivity of the ‘Incident Details’ data of the ‘Assess liability’ function.
What is the current objective of the ‘Incident Details’ data of the ‘Assess Liability’ function? What is the deviation of the current objective from the desired one?
Caller witnessed incident?
Yes
Corroborating witnesses exist?
Yes
Believability To improve the believability of the ‘Incident Details’ data of the ‘Assess liability’ function.
What is the current believability of the ‘Incident Details’ data of the ‘Assess Liability’ function? What is the deviation of the current believability from the desired one?
Caller witnessed incident?
Yes
Corroborating witnesses exist?
Yes
Reputation To improve the reputation of the ‘Incident Details’ data of the ‘Assess liability’ function.
What is the current reputation of the ‘Incident Details’ data of the ‘Assess Liability’ function? What is the deviation of the current reputation from the desired one?
Caller witnessed incident?
Yes
Corroborating witnesses exist?
Yes
Accessibility To improve the accessibility of the ‘Incident Details’ data of the ‘Assess liability’ function.
What is the current accessibility of the ‘Incident Details’ data of the ‘Assess Liability’ function? What is the deviation of the current accessibility from the desired one?
Location of Data
= System A
371
Relevancy To improve the relevancy of the ‘Incident Details’ data of the ‘Assess liability’ function.
What is the current relevancy of the ‘Incident Details’ data of the ‘Assess Liability’ function? What is the deviation of the current relevancy from the desired one?
Motor vehicle incident related
Yes
Value-added To increase the value-added of the ‘Incident Details’ data of the ‘Assess liability’ function.
What is the current added value of the ‘Incident Details’ data of the ‘Assess Liability’ function? What is the deviation of the current added value from the desired one?
Incident detail is descriptive
Yes
Security To increase the security of the ‘Incident Details’ data of the ‘Assess liability’ function.
What is the current security of the ‘Incident Details’ data of the ‘Assess Liability’ function? What is the deviation of the current security from the desired one?
Is audited? Yes
Completeness To improve the completeness of the ‘Incident Details’ data of the ‘Assess liability’ function.
What is the current completeness of the ‘Incident Details’ data of the ‘Assess Liability’ function? What is the deviation of the current completeness from the desired one?
All mandatory details exist
Yes
Amount of Data
To improve the amount of data of the ‘Incident Details’ data of the ‘Assess liability’ function.
What is the current amount of data of the ‘Incident Details’ data of the ‘Assess Liability’ function? What is the deviation of the current amount of data from the desired one?
Enough data exists to define incident
Yes
Timeliness To improve the timeliness of the ‘Incident Details’ data of the ‘Assess liability’ function.
What is the current timeliness of the ‘Incident Details’ data of the ‘Assess Liability’ function? What is the deviation of the current timeliness from the desired one?
Time since incident
< 1 month
Claim Business Rules
Accuracy To improve the accuracy of the ‘Claim Business Rules’ data of the ‘Assess liability’ function.
What is the current accuracy of the ‘Claim Business Rules’ data of the ‘Assess Liability’ function? What is the deviation of the current accuracy from the desired one?
Subjective evaluation
n/a
Objectivity To improve the objectivity of the ‘Claim
What is the current objectivity of the ‘Claim Business Rules’ data of the ‘Assess
Source of data
Published policy
372
Business Rules’ data of the ‘Assess liability’ function.
Liability’ function? What is the deviation of the current objectivity from the desired one?
Believability To improve the believability of the ‘Claim Business Rules’ data of the ‘Assess liability’ function.
What is the current believability of the ‘Claim Business Rules’ data of the ‘Assess Liability’ function? What is the deviation of the current believability from the desired one?
Source of data
Published policy
Reputation To improve the reputation of the ‘Claim Business Rules’ data of the ‘Assess liability’ function.
What is the current reputation of the ‘Claim Business Rules’ data of the ‘Assess Liability’ function? What is the deviation of the current reputation from the desired one?
Source of data
Published policy
Accessibility To improve the accessibility of the ‘Claim Business Rules’ data of the ‘Assess liability’ function.
What is the current accessibility of the ‘Claim Business Rules’ data of the ‘Assess Liability’ function? What is the deviation of the current accessibility from the desired one?
Storage method
= electronic
Relevancy To improve the relevancy of the ‘Claim Business Rules’ data of the ‘Assess liability’ function.
What is the current relevancy of the ‘Claim Business Rules’ data of the ‘Assess Liability’ function? What is the deviation of the current relevancy from the desired one?
Related to appropriate policy
Yes
Value-added To increase the value-added of the ‘Claim Business Rules’ data of the ‘Assess liability’ function.
What is the current added value of the ‘Claim Business Rules’ data of the ‘Assess Liability’ function? What is the deviation of the current added value from the desired one?
Business rules are descriptive
Yes
Security To increase the security of the ‘Claim Business Rules’ data of the ‘Assess liability’ function.
What is the current security of the ‘Claim Business Rules’ data of the ‘Assess Liability’ function? What is the deviation of the current security from the desired one?
User has access
Yes
Completeness To improve the completeness of the ‘Claim Business Rules’ data of the ‘Assess
What is the current completeness of the ‘Claim Business Rules’ data of the ‘Assess Liability’ function? What is the deviation of the current completeness from the
Rules describe all possible cases
Yes
373
liability’ function. desired one?
Amount of Data
To improve the amount of data of the ‘Claim Business Rules’ data of the ‘Assess liability’ function.
What is the current amount of data of the ‘Claim Business Rules’ data of the ‘Assess Liability’ function? What is the deviation of the current amount of data from the desired one?
Enough information exists to validate incident coverage
Yes
Timeliness To improve the timeliness of the ‘Claim Business Rules’ data of the ‘Assess liability’ function.
What is the current timeliness of the ‘Claim Business Rules’ data of the ‘Assess Liability’ function? What is the deviation of the current timeliness from the desired one?
Age of Data = Current
F6 - Capture loss and TP details
Vehicle Identification
Reputation To improve the reputation of the ‘Vehicle Identification’ data of the ‘Capture loss and TP details’ function.
What is the current reputation of the ‘Vehicle Identification’ data of the ‘Capture loss and TP details’ function? What is the deviation of the current reputation from the desired one?
Source of data
= Policyholder
Relevancy To improve the relevancy of the ‘Vehicle Identification’ data of the ‘Capture loss and TP details’ function.
What is the current relevancy of the ‘Vehicle Identification’ data of the ‘Capture loss and TP details’ function? What is the deviation of the current relevancy from the desired one?
Describes vehicle identity
Yes
Timeliness To improve the timeliness of the ‘Vehicle Identification’ data of the ‘Capture loss and TP details’ function.
What is the current timeliness of the ‘Vehicle Identification’ data of the ‘Capture loss and TP details’ function? What is the deviation of the current timeliness from the desired one?
Age of Data = current
Completeness To improve the completeness of the ‘Vehicle Identification’ data of the ‘Capture loss and TP details’ function.
What is the current completeness of the ‘Vehicle Identification’ data of the ‘Capture loss and TP details’ function? What is the deviation of the current completeness from the desired one?
All fields present that confirm identification
Yes
Amount of Data
To improve the amount of data of the ‘Vehicle Identification’ data of the ‘Capture loss and TP
What is the current amount of data of the ‘Vehicle Identification’ data of the ‘Capture loss and TP details’ function? What is the deviation of the current
Enough data exists to confirm identification
Yes
374
details’ function. amount of data from the desired one?
Driver Details Reputation To improve the reputation of the ‘Driver Details’ data of the ‘Capture loss and TP details’ function.
What is the current reputation of the ‘Driver Details’ data of the ‘Capture loss and TP details’ function? What is the deviation of the current reputation from the desired one?
Policy holder was driver?
Yes
Relevancy To improve the relevancy of the ‘Driver Details’ data of the ‘Capture loss and TP details’ function.
What is the current relevancy of the ‘Driver Details’ data of the ‘Capture loss and TP details’ function? What is the deviation of the current relevancy from the desired one?
Describes driver
Yes
Security To increase the security of the ‘Driver Details’ data of the ‘Capture loss and TP details’ function.
What is the current security of the ‘Driver Details’ data of the ‘Capture loss and TP details’ function? What is the deviation of the current security from the desired one?
Yes
Timeliness To improve the timeliness of the ‘Driver Details’ data of the ‘Capture loss and TP details’ function.
What is the current timeliness of the ‘Driver Details’ data of the ‘Capture loss and TP details’ function? What is the deviation of the current timeliness from the desired one?
Age of Data < 1 month
Completeness To improve the completeness of the ‘Driver Details’ data of the ‘Capture loss and TP details’ function.
What is the current completeness of the ‘Driver Details’ data of the ‘Capture loss and TP details’ function? What is the deviation of the current completeness from the desired one?
All fields present that confirm driver
Yes
Amount of Data
To improve the amount of data of the ‘Driver Details’ data of the ‘Capture loss and TP details’ function.
What is the current amount of data of the ‘Driver Details’ data of the ‘Capture loss and TP details’ function? What is the deviation of the current amount of data from the desired one?
Enough data exists to confirm identification
Yes
Accessibility To improve the accessibility of the ‘Driver Details’ data of the ‘Capture loss and TP details’ function.
What is the current accessibility of the ‘Driver Details’ data of the ‘Capture loss and TP details’ function? What is the deviation of the current accessibility from the desired one?
Storage Method
=Electronic
375
Customer Vehicle Details - Damage
Accuracy To improve the accuracy of the ‘Customer Vehicle Details - Damage’ data of the ‘Capture loss and TP details’ function.
What is the current accuracy of the ‘Customer Vehicle Details - Damage’ data of the ‘Capture loss and TP details’ function? What is the deviation of the current accuracy from the desired one?
Subjective evaluation
n/a
Objectivity To improve the objectivity of the ‘Customer Vehicle Details - Damage’ data of the ‘Capture loss and TP details’ function.
What is the current objectivity of the ‘Customer Vehicle Details - Damage’ data of the ‘Capture loss and TP details’ function? What is the deviation of the current objectivity from the desired one?
Source of data
= approved vehicle inspector
Believability To improve the believability of the ‘Customer Vehicle Details - Damage’ data of the ‘Capture loss and TP details’ function.
What is the current believability of the ‘Customer Vehicle Details - Damage’ data of the ‘Capture loss and TP details’ function? What is the deviation of the current believability from the desired one?
Source of data
= approved vehicle inspector
Reputation To improve the reputation of the ‘Customer Vehicle Details - Damage’ data of the ‘Capture loss and TP details’ function.
What is the current reputation of the ‘Customer Vehicle Details - Damage’ data of the ‘Capture loss and TP details’ function? What is the deviation of the current reputation from the desired one?
Source of data
= approved vehicle inspector
Relevancy To improve the relevancy of the ‘Customer Vehicle Details - Damage’ data of the ‘Capture loss and TP details’ function.
What is the current relevancy of the ‘Customer Vehicle Details - Damage’ data of the ‘Capture loss and TP details’ function? What is the deviation of the current relevancy from the desired one?
Damage described
Yes
Security To increase the security of the ‘Customer Vehicle Details - Damage’ data of the ‘Capture loss and TP details’ function.
What is the current security of the ‘Customer Vehicle Details - Damage’ data of the ‘Capture loss and TP details’ function? What is the deviation of the current security from the desired one?
Is audited Yes
376
Timeliness To improve the timeliness of the ‘Customer Vehicle Details - Damage’ data of the ‘Capture loss and TP details’ function.
What is the current timeliness of the ‘Customer Vehicle Details - Damage’ data of the ‘Capture loss and TP details’ function? What is the deviation of the current timeliness from the desired one?
Time since incident
< 14 days
Completeness To improve the completeness of the ‘Customer Vehicle Details - Damage’ data of the ‘Capture loss and TP details’ function.
What is the current completeness of the ‘Customer Vehicle Details - Damage’ data of the ‘Capture loss and TP details’ function? What is the deviation of the current completeness from the desired one?
All fields present that describe vehicle damage
Yes
Amount of Data
To improve the amount of data of the ‘Customer Vehicle Details - Damage’ data of the ‘Capture loss and TP details’ function.
What is the current amount of data of the ‘Customer Vehicle Details - Damage’ data of the ‘Capture loss and TP details’ function? What is the deviation of the current amount of data from the desired one?
Enough data exists to describe vehicle damage
Yes
Accessibility To improve the accessibility of the ‘Customer Vehicle Details - Damage’ data of the ‘Capture loss and TP details’ function.
What is the current accessibility of the ‘Customer Vehicle Details - Damage’ data of the ‘Capture loss and TP details’ function? What is the deviation of the current accessibility from the desired one?
Storage Method
= electronic
Customer Personal Property
Reputation To improve the reputation of the ‘Customer Personal Property’ data of the ‘Capture loss and TP details’ function.
What is the current relevancy of the ‘Customer Personal Property’ data of the ‘Capture loss and TP details’ function? What is the deviation of the current relevancy from the desired one?
Source of data
=Policyholder
Relevancy To improve the relevancy of the ‘Customer Personal Property’ data of the ‘Capture loss and TP details’ function.
What is the current relevancy of the ‘Customer Personal Property’ data of the ‘Capture loss and TP details’ function? What is the deviation of the current relevancy from the desired one?
Data describes customer personal property
Yes
Security To increase the security of the ‘Customer
What is the current security of the ‘Customer Personal Property’ data of the
Is audited Yes
377
Personal Property’ data of the ‘Capture loss and TP details’ function.
‘Capture loss and TP details’ function? What is the deviation of the current security from the desired one?
Timeliness To improve the timeliness of the ‘Customer Personal Property’ data of the ‘Capture loss and TP details’ function.
What is the current timeliness of the ‘Customer Personal Property’ data of the ‘Capture loss and TP details’ function? What is the deviation of the current timeliness from the desired one?
Time since incident
< 14 days
Accessibility To improve the accessibility of the ‘Customer Personal Property’ data of the ‘Capture loss and TP details’ function.
What is the current accessibility of the ‘Customer Personal Property’ data of the ‘Capture loss and TP details’ function? What is the deviation of the current accessibility from the desired one?
Storage Method
= electronic
Third Party Details
Relevancy To improve the relevancy of the ‘Third Party Details’ data of the ‘Capture loss and TP details’ function.
What is the current relevancy of the ‘Third Party Details’ data of the ‘Capture loss and TP details’ function? What is the deviation of the current relevancy from the desired one?
Are details verified
Yes
Value-added To increase the value-added of the ‘Third Party Details’ data of the ‘Capture loss and TP details’ function.
What is the current added value of the ‘Third Party Details’ data of the ‘Capture loss and TP details’ function? What is the deviation of the current added value from the desired one?
Describes third party details
Yes
Security To increase the security of the ‘Third Party Details’ data of the ‘Capture loss and TP details’ function.
What is the current security of the ‘Third Party Details’ data of the ‘Capture loss and TP details’ function? What is the deviation of the current security from the desired one?
Is user authorised
Yes
Timeliness To improve the timeliness of the ‘Third Party Details’ data of the ‘Capture loss and TP details’ function.
What is the current timeliness of the ‘Third Party Details’ data of the ‘Capture loss and TP details’ function? What is the deviation of the current timeliness from the desired one?
Time since incident
< 14 days
Completeness To improve the completeness of the
What is the current completeness of the ‘Third Party Details’ data of the ‘Capture
All fields present that
Yes
378
‘Third Party Details’ data of the ‘Capture loss and TP details’ function.
loss and TP details’ function? What is the deviation of the current completeness from the desired one?
describe third party
Amount of Data
To improve the amount of data of the ‘Third Party Details’ data of the ‘Capture loss and TP details’ function.
What is the current amount of data of the ‘Third Party Details’ data of the ‘Capture loss and TP details’ function? What is the deviation of the current amount of data from the desired one?
Enough data exists to describe third party
Yes
Accessibility To improve the accessibility of the ‘Third Party Details’ data of the ‘Capture loss and TP details’ function.
What is the current accessibility of the ‘Third Party Details’ data of the ‘Capture loss and TP details’ function? What is the deviation of the current accessibility from the desired one?
Storage Method
=electronic
Other Party Details
Objectivity To improve the objectivity of the ‘Other Party Details’ data of the ‘Capture loss and TP details’ function.
What is the current objectivity of the ‘Other Party Details’ data of the ‘Capture loss and TP details’ function? What is the deviation of the current objectivity from the desired one?
Source of data
=Policyholder
Believability To improve the believability of the ‘Other Party Details’ data of the ‘Capture loss and TP details’ function.
What is the current believability of the ‘Other Party Details’ data of the ‘Capture loss and TP details’ function? What is the deviation of the current believability from the desired one?
Source of data
=Policyholder
Relevancy To improve the relevancy of the ‘Other Party Details’ data of the ‘Capture loss and TP details’ function.
What is the current relevancy of the ‘Other Party Details’ data of the ‘Capture loss and TP details’ function? What is the deviation of the current relevancy from the desired one?
Are details verified
Yes
Security To increase the security of the ‘Other Party Details’ data of the ‘Capture loss and TP details’ function.
What is the current security of the ‘Other Party Details’ data of the ‘Capture loss and TP details’ function? What is the deviation of the current security from the desired one?
Is user authorised
Yes
Timeliness To improve the timeliness of the ‘Other Party Details’ data of the ‘Capture loss and TP
What is the current timeliness of the ‘Other Party Details’ data of the ‘Capture loss and TP details’ function? What is the deviation of the current timeliness from
Time since incident
< 14 days
379
details’ function. the desired one?
Completeness To improve the completeness of the ‘Other Party Details’ data of the ‘Capture loss and TP details’ function.
What is the current completeness of the ‘Other Party Details’ data of the ‘Capture loss and TP details’ function? What is the deviation of the current completeness from the desired one?
All fields present that describe other party details
Yes
Amount of Data
To improve the amount of data of the ‘Other Party Details’ data of the ‘Capture loss and TP details’ function.
What is the current amount of data of the ‘Other Party Details’ data of the ‘Capture loss and TP details’ function? What is the deviation of the current amount of data from the desired one?
Enough data exists to describe third party
Yes
F7 - Assess excess
Coverage and Policy Extras
Accuracy To improve the accuracy of the ‘Coverage and Policy Extras’ data of the ‘Assess excess’ function.
What is the current accuracy of the ‘Coverage and Policy Extras’ data of the ‘Assess excess’ function? What is the deviation of the current accuracy from the desired one?
Subjective evaluation
n/a
Objectivity To improve the objectivity of the ‘Coverage and Policy Extras’ data of the ‘Assess excess’ function.
What is the current objectivity of the ‘Coverage and Policy Extras’ data of the ‘Assess excess’ function? What is the deviation of the current objectivity from the desired one?
Source of data
= System A
Believability To improve the believability of the ‘Coverage and Policy Extras’ data of the ‘Assess excess’ function.
What is the current believability of the ‘Coverage and Policy Extras’ data of the ‘Assess excess’ function? What is the deviation of the current believability from the desired one?
Source of data
= System A
Reputation To improve the reputation of the ‘Coverage and Policy Extras’ data of the ‘Assess excess’ function.
What is the current reputation of the ‘Coverage and Policy Extras’ data of the ‘Assess excess’ function? What is the deviation of the current reputation from the desired one?
Source of data
= System A
Accessibility To improve the accessibility of the ‘Coverage and Policy Extras’ data of the ‘Assess excess’ function.
What is the current reputation of the ‘Coverage and Policy Extras’ data of the ‘Assess excess’ function? What is the deviation of the current reputation from the desired one?
Location of Data
= System A
380
Relevancy To improve the relevancy of the ‘Coverage and Policy Extras’ data of the ‘Assess excess’ function.
What is the current relevancy of the ‘Coverage and Policy Extras’ data of the ‘Assess excess’ function? What is the deviation of the current relevancy from the desired one?
Subjective evaluation
n/a
Security To increase the security of the ‘Coverage and Policy Extras’ data of the ‘Assess excess’ function.
What is the current security of the ‘Coverage and Policy Extras’ data of the ‘Assess excess’ function? What is the deviation of the current security from the desired one?
User can access data
Yes
Completeness To improve the completeness of the ‘Coverage and Policy Extras’ data of the ‘Assess excess’ function.
What is the current completeness of the ‘Coverage and Policy Extras’ data of the ‘Assess excess’ function? What is the deviation of the current completeness from the desired one?
All fields present that confirm policy coverage
Yes
Amount of Data
To improve the amount of data of the ‘Coverage and Policy Extras’ data of the ‘Assess excess’ function.
What is the current amount of data of the ‘Coverage and Policy Extras’ data of the ‘Assess excess’ function? What is the deviation of the current amount of data from the desired one?
Enough data exists to confirm policy coverage
Yes
Timeliness To improve the timeliness of the ‘Coverage and Policy Extras’ data of the ‘Assess excess’ function.
What is the current timeliness of the ‘Coverage and Policy Extras’ data of the ‘Assess excess’ function? What is the deviation of the current timeliness from the desired one?
Age of Data < 1 month
Vehicle Information
Accuracy To improve the accuracy of the ‘Vehicle Information’ data of the ‘Assess excess’ function.
What is the current accuracy of the ‘Vehicle Information’ data of the ‘Assess excess’ function? What is the deviation of the current accuracy from the desired one?
Subjective evaluation
n/a
Objectivity To improve the objectivity of the ‘Vehicle Information’ data of the ‘Assess excess’ function.
What is the current objectivity of the ‘Vehicle Information’ data of the ‘Assess excess’ function? What is the deviation of the current objectivity from the desired one?
Source of Data
= System A
Believability To improve the believability of the
What is the current believability of the ‘Vehicle Information’ data of the ‘Assess
Source of Data
= System A
381
‘Vehicle Information’ data of the ‘Assess excess’ function.
excess’ function? What is the deviation of the current believability from the desired one?
Reputation To improve the reputation of the ‘Vehicle Information’ data of the ‘Assess excess’ function.
What is the current reputation of the ‘Vehicle Information’ data of the ‘Assess excess’ function? What is the deviation of the current reputation from the desired one?
Source of Data
= System A
Relevancy To improve the relevancy of the ‘Vehicle Information’ data of the ‘Assess excess’ function.
What is the current relevancy of the ‘Vehicle Information’ data of the ‘Assess excess’ function? What is the deviation of the current relevancy from the desired one?
Describes vehicle
Yes
Completeness To improve the completeness of the ‘Vehicle Information’ data of the ‘Assess excess’ function.
What is the current completeness of the ‘Vehicle Information’ data of the ‘Assess excess’ function? What is the deviation of the current completeness from the desired one?
All fields present that describe vehicle
Yes
Amount of Data
To improve the amount of data of the ‘Vehicle Information’ data of the ‘Assess excess’ function.
What is the current amount of data of the ‘Vehicle Information’ data of the ‘Assess excess’ function? What is the deviation of the current amount of data from the desired one?
Enough data exists to describe vehicle
Yes
Timeliness To improve the timeliness of the ‘Vehicle Information’ data of the ‘Assess excess’ function.
What is the current timeliness of the ‘Vehicle Information’ data of the ‘Assess excess’ function? What is the deviation of the current timeliness from the desired one?
Age of Data < 2 years
Incident Details Accuracy To improve the accuracy of the ‘Incident Details’ data of the ‘Assess excess’ function.
What is the current accuracy of the ‘Incident Details’ data of the ‘Assess excess’ function? What is the deviation of the current accuracy from the desired one?
Subjective evaluation
n/a
Objectivity To improve the objectivity of the ‘Incident Details’ data of the ‘Assess excess’
What is the current objectivity of the ‘Incident Details’ data of the ‘Assess excess’ function? What is the deviation of the current objectivity from the desired
Caller witnessed incident?
Yes
382
function. one?
Corroborating witnesses exist?
Yes
Believability To improve the believability of the ‘Incident Details’ data of the ‘Assess excess’ function.
What is the current believability of the ‘Incident Details’ data of the ‘Assess excess’ function? What is the deviation of the current believability from the desired one?
Caller witnessed incident?
Yes
Corroborating witnesses exist?
Yes
Reputation To improve the reputation of the ‘Incident Details’ data of the ‘Assess excess’ function.
What is the current reputation of the ‘Incident Details’ data of the ‘Assess excess’ function? What is the deviation of the current reputation from the desired one?
Caller witnessed incident?
Yes
Corroborating witnesses exist?
Yes
Accessibility To improve the accessibility of the ‘Incident Details’ data of the ‘Assess excess’ function.
What is the current accessibility of the ‘Incident Details’ data of the ‘Assess excess’ function? What is the deviation of the current accessibility from the desired one?
Location of Data
= System A
Relevancy To improve the relevancy of the ‘Incident Details’ data of the ‘Assess excess’ function.
What is the current relevancy of the ‘Incident Details’ data of the ‘Assess excess’ function? What is the deviation of the current relevancy from the desired one?
Motor vehicle incident related
Yes
Value-added To increase the value-added of the ‘Incident Details’ data of the ‘Assess excess’ function.
What is the current added value of the ‘Incident Details’ data of the ‘Assess excess’ function? What is the deviation of the current added value from the desired one?
Incident detail is descriptive
Yes
383
Security To increase the security of the ‘Incident Details’ data of the ‘Assess excess’ function.
What is the current security of the ‘Incident Details’ data of the ‘Assess excess’ function? What is the deviation of the current security from the desired one?
Is audited Yes
Completeness To improve the completeness of the ‘Incident Details’ data of the ‘Assess excess’ function.
What is the current completeness of the ‘Incident Details’ data of the ‘Assess excess’ function? What is the deviation of the current completeness from the desired one?
All mandatory details exist
Yes
Amount of Data
To improve the amount of data of the ‘Incident Details’ data of the ‘Assess excess’ function.
What is the current amount of data of the ‘Incident Details’ data of the ‘Assess excess’ function? What is the deviation of the current amount of data from the desired one?
Enough data exists to define incident
Yes
Timeliness To improve the timeliness of the ‘Incident Details’ data of the ‘Assess excess’ function.
What is the current timeliness of the ‘Incident Details’ data of the ‘Assess excess’ function? What is the deviation of the current timeliness from the desired one?
Time since incident
< 1 month
Claim Business Rules
Accuracy To improve the accuracy of the ‘Claim Business Rules’ data of the ‘Assess excess’ function.
What is the current accuracy of the ‘Claim Business Rules’ data of the ‘Assess excess’ function? What is the deviation of the current accuracy from the desired one?
Subjective evaluation
n/a
Objectivity To improve the objectivity of the ‘Claim Business Rules’ data of the ‘Assess excess’ function.
What is the current objectivity of the ‘Claim Business Rules’ data of the ‘Assess excess’ function? What is the deviation of the current objectivity from the desired one?
Source of data
Published policy
Believability To improve the believability of the ‘Claim Business Rules’ data of the ‘Assess excess’ function.
What is the current believability of the ‘Claim Business Rules’ data of the ‘Assess excess’ function? What is the deviation of the current believability from the desired one?
Source of data
Published policy
Reputation To improve the reputation of the ‘Claim
What is the current reputation of the ‘Claim Business Rules’ data of the ‘Assess
Source of data
Published policy
384
Business Rules’ data of the ‘Assess excess’ function.
excess’ function? What is the deviation of the current reputation from the desired one?
Accessibility To improve the accessibility of the ‘Claim Business Rules’ data of the ‘Assess excess’ function.
What is the current accessibility of the ‘Claim Business Rules’ data of the ‘Assess excess’ function? What is the deviation of the current accessibility from the desired one?
Storage Method
= electronic
Relevancy To improve the relevancy of the ‘Claim Business Rules’ data of the ‘Assess excess’ function.
What is the current relevancy of the ‘Claim Business Rules’ data of the ‘Assess excess’ function? What is the deviation of the current relevancy from the desired one?
Related to appropriate policy
Yes
Value-added To increase the value-added of the ‘Claim Business Rules’ data of the ‘Assess excess’ function.
What is the current added value of the ‘Claim Business Rules’ data of the ‘Assess excess’ function? What is the deviation of the current added value from the desired one?
Business rules are descriptive
Yes
Security To increase the security of the ‘Claim Business Rules’ data of the ‘Assess excess’ function.
What is the current security of the ‘Claim Business Rules’ data of the ‘Assess excess’ function? What is the deviation of the current security from the desired one?
User has access
Yes
Completeness To improve the completeness of the ‘Claim Business Rules’ data of the ‘Assess excess’ function.
What is the current completeness of the ‘Claim Business Rules’ data of the ‘Assess excess’ function? What is the deviation of the current completeness from the desired one?
Rules describe all possible cases
Yes
Amount of Data
To improve the amount of data of the ‘Claim Business Rules’ data of the ‘Assess excess’ function.
What is the current amount of data of the ‘Claim Business Rules’ data of the ‘Assess excess’ function? What is the deviation of the current amount of data from the desired one?
Enough information exists to validate incident coverage
Yes
Timeliness To improve the timeliness of the ‘Claim Business Rules’ data of the ‘Assess excess’
What is the current timeliness of the ‘Claim Business Rules’ data of the ‘Assess excess’ function? What is the deviation of the current timeliness from the desired
Age of Data = Current
385
function. one?
F8 - Assess pathing
Incident Details Accuracy To improve the accuracy of the ‘Incident Details’ data of the ‘Assess pathing’ function.
What is the current accuracy of the ‘Incident Details’ data of the ‘Assess pathing’ function? What is the deviation of the current accuracy from the desired one?
Subjective evaluation
n/a
Objectivity To improve the objectivity of the ‘Incident Details’ data of the ‘Assess pathing’ function.
What is the current objectivity of the ‘Incident Details’ data of the ‘Assess pathing’ function? What is the deviation of the current objectivity from the desired one?
Caller witnessed incident?
Yes
Corroborating witnesses exist?
Yes
Believability To improve the believability of the ‘Incident Details’ data of the ‘Assess pathing’ function.
What is the current believability of the ‘Incident Details’ data of the ‘Assess pathing’ function? What is the deviation of the current believability from the desired one?
Caller witnessed incident?
Yes
Corroborating witnesses exist?
Yes
Reputation To improve the reputation of the ‘Incident Details’ data of the ‘Assess pathing’ function.
What is the current reputation of the ‘Incident Details’ data of the ‘Assess pathing’ function? What is the deviation of the current reputation from the desired one?
Caller witnessed incident?
Yes
Corroborating witnesses exist?
Yes
Accessibility To improve the accessibility of the ‘Incident Details’ data of the ‘Assess pathing’ function.
What is the current accessibility of the ‘Incident Details’ data of the ‘Assess pathing’ function? What is the deviation of the current accessibility from the desired one?
Location of Data
= System A
386
Relevancy To improve the relevancy of the ‘Incident Details’ data of the ‘Assess pathing’ function.
What is the current relevancy of the ‘Incident Details’ data of the ‘Assess pathing’ function? What is the deviation of the current relevancy from the desired one?
Motor vehicle incident related
Yes
Value-added To increase the value-added of the ‘Incident Details’ data of the ‘Assess pathing’ function.
What is the current added value of the ‘Incident Details’ data of the ‘Assess pathing’ function? What is the deviation of the current added value from the desired one?
Incident detail is descriptive
Yes
Security To increase the security of the ‘Incident Details’ data of the ‘Assess pathing’ function.
What is the current security of the ‘Incident Details’ data of the ‘Assess pathing’ function? What is the deviation of the current security from the desired one?
Is audited? Yes
Completeness To improve the completeness of the ‘Incident Details’ data of the ‘Assess pathing’ function.
What is the current completeness of the ‘Incident Details’ data of the ‘Assess pathing’ function? What is the deviation of the current completeness from the desired one?
All mandatory details exist
Yes
Amount of Data
To improve the amount of data of the ‘Incident Details’ data of the ‘Assess pathing’ function.
What is the current amount of data of the ‘Incident Details’ data of the ‘Assess pathing’ function? What is the deviation of the current amount of data from the desired one?
Enough data exists to define incident
Yes
Timeliness To improve the timeliness of the ‘Incident Details’ data of the ‘Assess pathing’ function.
What is the current timeliness of the ‘Incident Details’ data of the ‘Assess pathing’ function? What is the deviation of the current timeliness from the desired one?
Time since incident
< 1 month
Customer Vehicle Details - Damage
Accuracy To improve the accuracy of the ‘Customer Vehicle Details - Damage’ data of the ‘Assess pathing’ function.
What is the current accuracy of the ‘Customer Vehicle Details - Damage’ data of the ‘Assess pathing’ function? What is the deviation of the current accuracy from the desired one?
Subjective evaluation
n/a
Objectivity To improve the objectivity of the
What is the current objectivity of the ‘Customer Vehicle Details - Damage’ data
Source of data
= approved vehicle
387
‘Customer Vehicle Details - Damage’ data of the ‘Assess pathing’ function.
of the ‘Assess pathing’ function? What is the deviation of the current objectivity from the desired one?
inspector
Believability To improve the believability of the ‘Customer Vehicle Details - Damage’ data of the ‘Assess pathing’ function.
What is the current believability of the ‘Customer Vehicle Details - Damage’ data of the ‘Assess pathing’ function? What is the deviation of the current believability from the desired one?
Source of data
= approved vehicle inspector
Reputation To improve the reputation of the ‘Customer Vehicle Details - Damage’ data of the ‘Assess pathing’ function.
What is the current reputation of the ‘Customer Vehicle Details - Damage’ data of the ‘Assess pathing’ function? What is the deviation of the current reputation from the desired one?
Source of data
= approved vehicle inspector
Accessibility To improve the accessibility of the ‘Customer Vehicle Details - Damage’ data of the ‘Assess pathing’ function.
What is the current accessibility of the ‘Customer Vehicle Details - Damage’ data of the ‘Assess pathing’ function? What is the deviation of the current accessibility from the desired one?
Storage Method
= electronic
Relevancy To improve the relevancy of the ‘Customer Vehicle Details - Damage’ data of the ‘Assess pathing’ function.
What is the current relevancy of the ‘Customer Vehicle Details - Damage’ data of the ‘Assess pathing’ function? What is the deviation of the current relevancy from the desired one?
Damage described
Yes
Security To increase the security of the ‘Customer Vehicle Details - Damage’ data of the ‘Assess pathing’ function.
What is the current security of the ‘Customer Vehicle Details - Damage’ data of the ‘Assess pathing’ function? What is the deviation of the current security from the desired one?
Is audited Yes
Completeness To improve the completeness of the ‘Customer Vehicle Details - Damage’ data of the ‘Assess pathing’
What is the current completeness of the ‘Customer Vehicle Details - Damage’ data of the ‘Assess pathing’ function? What is the deviation of the current completeness from the desired one?
All fields present that describe vehicle damage
Yes
388
function.
Amount of Data
To improve the amount of data of the ‘Customer Vehicle Details - Damage’ data of the ‘Assess pathing’ function.
What is the current amount of data of the ‘Customer Vehicle Details - Damage’ data of the ‘Assess pathing’ function? What is the deviation of the current amount of data from the desired one?
Enough data exists to describe vehicle damage
Yes
Timeliness To improve the timeliness of the ‘Customer Vehicle Details - Damage’ data of the ‘Assess pathing’ function.
What is the current timeliness of the ‘Customer Vehicle Details - Damage’ data of the ‘Assess pathing’ function? What is the deviation of the current timeliness from the desired one?
Time since incident
< 14 days
Assessment Details
Accuracy To improve the accuracy of the ‘Assessment Details’ data of the ‘Assess pathing’ function.
What is the current accuracy of the ‘Assessment Details’ data of the ‘Assess pathing’ function? What is the deviation of the current accuracy from the desired one?
Subjective evaluation
n/a
Objectivity To improve the objectivity of the ‘Assessment Details’ data of the ‘Assess pathing’ function.
What is the current objectivity of the ‘Assessment Details’ data of the ‘Assess pathing’ function? What is the deviation of the current objectivity from the desired one?
Calculation Method
System generated
Believability To improve the believability of the ‘Assessment Details’ data of the ‘Assess pathing’ function.
What is the current believability of the ‘Assessment Details’ data of the ‘Assess pathing’ function? What is the deviation of the current believability from the desired one?
Calculation Method
System generated
Reputation To improve the reputation of the ‘Assessment Details’ data of the ‘Assess pathing’ function.
What is the current reputation of the ‘Assessment Details’ data of the ‘Assess pathing’ function? What is the deviation of the current reputation from the desired one?
Calculation Method
System generated
Accessibility To improve the accessibility of the ‘Assessment Details’ data
What is the current accessibility of the ‘Assessment Details’ data of the ‘Assess pathing’ function? What is the deviation
Location of Data
= System A
389
of the ‘Assess pathing’ function.
of the current accessibility from the desired one?
Relevancy To improve the relevancy of the ‘Assessment Details’ data of the ‘Assess pathing’ function.
What is the current relevancy of the ‘Assessment Details’ data of the ‘Assess pathing’ function? What is the deviation of the current relevancy from the desired one?
Assessment outcome is defined
Yes
Value-added To increase the value-added of the ‘Assessment Details’ data of the ‘Assess pathing’ function.
What is the current added value of the ‘Assessment Details’ data of the ‘Assess pathing’ function? What is the deviation of the current added value from the desired one?
Describes assessment outcome
Yes
Completeness To improve the completeness of the ‘Assessment Details’ data of the ‘Assess pathing’ function.
What is the current completeness of the ‘Assessment Details’ data of the ‘Assess pathing’ function? What is the deviation of the current completeness from the desired one?
All fields present that describe assessment outcome
Yes
Amount of Data
To improve the amount of data of the ‘Assessment Details’ data of the ‘Assess pathing’ function.
What is the current amount of data of the ‘Assessment Details’ data of the ‘Assess pathing’ function? What is the deviation of the current amount of data from the desired one?
Enough data exists to describe assessment outcome
Yes
Timeliness To improve the timeliness of the ‘Assessment Details’ data of the ‘Assess pathing’ function.
What is the current timeliness of the ‘Assessment Details’ data of the ‘Assess pathing’ function? What is the deviation of the current timeliness from the desired one?
Age of Data < 14 days
F9 - Action hire car and towing (as appropriate)
Coverage and Policy Extras
Accuracy To improve the accuracy of the ‘Coverage and Policy Extras’ data of the ‘Action hire car and towing’ function.
What is the current accuracy of the ‘Coverage and Policy Extras’ data of the ‘Action hire car and towing’ function? What is the deviation of the current accuracy from the desired one?
Subjective evaluation
n/a
Objectivity To improve the objectivity of the ‘Coverage and Policy Extras’ data of the ‘Action hire car and
What is the current objectivity of the ‘Coverage and Policy Extras’ data of the ‘Action hire car and towing’ function? What is the deviation of the current objectivity from the desired one?
Source of Data
= System A
390
towing’ function.
Believability To improve the believability of the ‘Coverage and Policy Extras’ data of the ‘Action hire car and towing’ function.
What is the current believability of the ‘Coverage and Policy Extras’ data of the ‘Action hire car and towing’ function? What is the deviation of the current believability from the desired one?
Source of Data
= System A
Reputation To improve the reputation of the ‘Coverage and Policy Extras’ data of the ‘Action hire car and towing’ function.
What is the current reputation of the ‘Coverage and Policy Extras’ data of the ‘Action hire car and towing’ function? What is the deviation of the current reputation from the desired one?
Source of Data
= System A
Relevancy To improve the relevancy of the ‘Coverage and Policy Extras’ data of the ‘Action hire car and towing’ function.
What is the current relevancy of the ‘Coverage and Policy Extras’ data of the ‘Action hire car and towing’ function? What is the deviation of the current relevancy from the desired one?
Subjective evaluation
n/a
Security To increase the security of the ‘Coverage and Policy Extras’ data of the ‘Action hire car and towing’ function.
What is the current security of the ‘Coverage and Policy Extras’ data of the ‘Action hire car and towing’ function? What is the deviation of the current security from the desired one?
User can access data
Yes
Timeliness To improve the timeliness of the ‘Coverage and Policy Extras’ data of the ‘Action hire car and towing’ function.
What is the current timeliness of the ‘Coverage and Policy Extras’ data of the ‘Action hire car and towing’ function? What is the deviation of the current timeliness from the desired one?
Age of Data < 1 month
Completeness To improve the completeness of the ‘Coverage and Policy Extras’ data of the ‘Action hire car and towing’ function.
What is the current completeness of the ‘Coverage and Policy Extras’ data of the ‘Action hire car and towing’ function? What is the deviation of the current completeness from the desired one?
All fields present that confirm policy coverage
Yes
391
Amount of Data
To improve the amount of data of the ‘Coverage and Policy Extras’ data of the ‘Action hire car and towing’ function.
What is the current amount of data of the ‘Coverage and Policy Extras’ data of the ‘Action hire car and towing’ function? What is the deviation of the current amount of data from the desired one?
Enough data exists to confirm policy coverage
Yes
Customer Vehicle Details - Damage
Accuracy To improve the accuracy of the ‘Customer Vehicle Details - Damage’ data of the ‘Action hire car and towing’ function.
What is the current accuracy of the ‘Customer Vehicle Details - Damage’ data of the ‘Action hire car and towing’ function? What is the deviation of the current accuracy from the desired one?
Subjective evaluation
n/a
Objectivity To improve the objectivity of the ‘Customer Vehicle Details - Damage’ data of the ‘Action hire car and towing’ function.
What is the current objectivity of the ‘Customer Vehicle Details - Damage’ data of the ‘Action hire car and towing’ function? What is the deviation of the current objectivity from the desired one?
Source of data
= approved vehicle inspector
Believability To improve the believability of the ‘Customer Vehicle Details - Damage’ data of the ‘Action hire car and towing’ function.
What is the current believability of the ‘Customer Vehicle Details - Damage’ data of the ‘Action hire car and towing’ function? What is the deviation of the current believability from the desired one?
Source of data
= approved vehicle inspector
Reputation To improve the reputation of the ‘Customer Vehicle Details - Damage’ data of the ‘Action hire car and towing’ function.
What is the current reputation of the ‘Customer Vehicle Details - Damage’ data of the ‘Action hire car and towing’ function? What is the deviation of the current reputation from the desired one?
Source of data
= approved vehicle inspector
Relevancy To improve the relevancy of the ‘Customer Vehicle Details - Damage’ data of the ‘Action hire car and towing’ function.
What is the current relevancy of the ‘Customer Vehicle Details - Damage’ data of the ‘Action hire car and towing’ function? What is the deviation of the current relevancy from the desired one?
Damage described
Yes
Security To increase the security of the ‘Customer Vehicle Details - Damage’ data of the ‘Action hire car
What is the current security of the ‘Customer Vehicle Details - Damage’ data of the ‘Action hire car and towing’ function? What is the deviation of the
Is audited Yes
392
and towing’ function. current security from the desired one?
Timeliness To improve the timeliness of the ‘Customer Vehicle Details - Damage’ data of the ‘Action hire car and towing’ function.
What is the current timeliness of the ‘Customer Vehicle Details - Damage’ data of the ‘Action hire car and towing’ function? What is the deviation of the current timeliness from the desired one?
Time since incident
< 14 days
Completeness To improve the completeness of the ‘Customer Vehicle Details - Damage’ data of the ‘Action hire car and towing’ function.
What is the current completeness of the ‘Customer Vehicle Details - Damage’ data of the ‘Action hire car and towing’ function? What is the deviation of the current completeness from the desired one?
All fields present that describe vehicle damage
Yes
Amount of Data
To improve the amount of data of the ‘Customer Vehicle Details - Damage’ data of the ‘Action hire car and towing’ function.
What is the current amount of data of the ‘Customer Vehicle Details - Damage’ data of the ‘Action hire car and towing’ function? What is the deviation of the current amount of data from the desired one?
Enough data exists to describe vehicle damage
Yes
Claim Services Accuracy To improve the accuracy of the ‘Claim Services’ data of the ‘Action hire car and towing’ function.
What is the current accuracy of the ‘Claim Services’ data of the ‘Action hire car and towing’ function? What is the deviation of the current accuracy from the desired one?
Subjective evaluation
n/a
Objectivity To improve the objectivity of the ‘Claim Services’ data of the ‘Action hire car and towing’ function.
What is the current objectivity of the ‘Claim Services’ data of the ‘Action hire car and towing’ function? What is the deviation of the current objectivity from the desired one?
Source of Data
Manual Selection
Believability To improve the believability of the ‘Claim Services’ data of the ‘Action hire car and towing’ function.
What is the current believability of the ‘Claim Services’ data of the ‘Action hire car and towing’ function? What is the deviation of the current believability from the desired one?
Source of Data
Manual Selection
Reputation To improve the reputation of the ‘Claim Services’ data of the
What is the current reputation of the ‘Claim Services’ data of the ‘Action hire car and towing’ function? What is the
Source of Data
Manual Selection
393
‘Action hire car and towing’ function.
deviation of the current reputation from the desired one?
Relevancy To improve the relevancy of the ‘Claim Services’ data of the ‘Action hire car and towing’ function.
What is the current relevancy of the ‘Claim Services’ data of the ‘Action hire car and towing’ function? What is the deviation of the current relevancy from the desired one?
Claim service are defined
Yes
Accessibility To improve the accessibility of the ‘Claim Services’ data of the ‘Action hire car and towing’ function.
What is the current accessibility of the ‘Claim Services’ data of the ‘Action hire car and towing’ function? What is the deviation of the current accessibility from the desired one?
Storage method
Electronic
Value-added To increase the value-added of the ‘Claim Services’ data of the ‘Action hire car and towing’ function.
What is the current added value of the ‘Claim Services’ data of the ‘Action hire car and towing’ function? What is the deviation of the current added value from the desired one?
Claim services are defined
Yes
Timeliness To improve the timeliness of the ‘Claim Services’ data of the ‘Action hire car and towing’ function.
What is the current timeliness of the ‘Claim Services’ data of the ‘Action hire car and towing’ function? What is the deviation of the current timeliness from the desired one?
Age of Data < 14 days
Completeness To improve the completeness of the ‘Claim Services’ data of the ‘Action hire car and towing’ function.
What is the current completeness of the ‘Claim Services’ data of the ‘Action hire car and towing’ function? What is the deviation of the current completeness from the desired one?
All fields present that describe claim services
Yes
Amount of Data
To improve the amount of data of the ‘Claim Services’ data of the ‘Action hire car and towing’ function.
What is the current amount of data of the ‘Claim Services’ data of the ‘Action hire car and towing’ function? What is the deviation of the current amount of data from the desired one?
Enough data exists to describe claim services
Yes
F10 - Add authorised parties (as appropriate)
Other Party Details
Reputation To improve the reputation of the ‘Other Party Details’ data of the ‘Add authorised parties’ function.
What is the current reputation of the ‘Other Party Details’ data of the ‘Add authorised parties’ function? What is the deviation of the current reputation from the desired one?
Source of data
=Policyholder
394
Relevancy To improve the relevancy of the ‘Other Party Details’ data of the ‘Add authorised parties’ function.
What is the current relevancy of the ‘Other Party Details’ data of the ‘Add authorised parties’ function? What is the deviation of the current relevancy from the desired one?
Are details verified
Yes
Accessibility To improve the accessibility of the ‘Other Party Details’ data of the ‘Add authorised parties’ function.
What is the current accessibility of the ‘Other Party Details’ data of the ‘Add authorised parties’ function? What is the deviation of the current accessibility from the desired one?
Storage Method
=electronic
Security To improve the security of the ‘Other Party Details’ data of the ‘Add authorised parties’ function.
What is the current security of the ‘Other Party Details’ data of the ‘Add authorised parties’ function? What is the deviation of the current security from the desired one?
Is user authorised
Yes
F11 - Inform customer of next steps
Claim Services Accuracy To improve the accuracy of the ‘Claim Services’ data of the ‘Inform customer of next steps’ function.
What is the current accuracy of the ‘Claim Services’ data of the ‘Inform customer of next steps’ function? What is the deviation of the current accuracy from the desired one?
Subjective evaluation
n/a
Objectivity To improve the objectivity of the ‘Claim Services’ data of the ‘Inform customer of next steps’ function.
What is the current objectivity of the ‘Claim Services’ data of the ‘Inform customer of next steps’ function? What is the deviation of the current objectivity from the desired one?
Source of Data
Manual Selection
Believability To improve the believability of the ‘Other Party Details’ data of the ‘Capture loss and TP details’ function.
What is the current believability of the ‘Claim Services’ data of the ‘Inform customer of next steps’ function? What is the deviation of the current believability from the desired one?
Source of Data
Manual Selection
Reputation To improve the reputation of the ‘Claim Services’ data of the ‘Inform customer of next steps’ function.
What is the current reputation of the ‘Claim Services’ data of the ‘Inform customer of next steps’ function? What is the deviation of the current reputation from the desired one?
Source of Data
Manual Selection
Relevancy To improve the relevancy of the ‘Claim
What is the current relevancy of the ‘Claim Services’ data of the ‘Inform
Claim service are defined
Yes
395
Services’ data of the ‘Inform customer of next steps’ function.
customer of next steps’ function? What is the deviation of the current relevancy from the desired one?
Accessibility To increase the accessibility of the ‘Claim Services’ data of the ‘Inform customer of next steps’ function.
What is the current accessibility of the ‘Claim Services’ data of the ‘Inform customer of next steps’ function? What is the deviation of the current accessibility from the desired one?
Storage method
Electronic
Value-added To increase the value-added of the ‘Claim Services’ data of the ‘Inform customer of next steps’ function.
What is the current added value of the ‘Claim Services’ data of the ‘Inform customer of next steps’ function? What is the deviation of the current added value from the desired one?
Claim services are defined
Yes
Timeliness To improve the timeliness of the ‘Claim Services’ data of the ‘Inform customer of next steps’ function.
What is the current timeliness of the ‘Claim Services’ data of the ‘Inform customer of next steps’ function? What is the deviation of the current timeliness from the desired one?
Age of Data < 14 days
Completeness To improve the completeness of the ‘Claim Services’ data of the ‘Inform customer of next steps’ function.
What is the current completeness of the ‘Claim Services’ data of the ‘Inform customer of next steps’ function? What is the deviation of the current completeness from the desired one?
All fields present that describe claim services
Yes
Amount of Data
To improve the amount of data of the ‘Claim Services’ data of the ‘Inform customer of next steps’ function.
What is the current amount of data of the ‘Claim Services’ data of the ‘Inform customer of next steps’ function? What is the deviation of the current amount of data from the desired one?
Enough data exists to describe claim services
Yes
Assessment Details
Accuracy To improve the accuracy of the ‘Assessment Details’ data of the ‘Inform customer of next steps’ function.
What is the current accuracy of the ‘Assessment Details’ data of the ‘Inform customer of next steps’ function? What is the deviation of the current accuracy from the desired one?
Subjective evaluation
n/a
Objectivity To improve the objectivity of the ‘Assessment Details’ data of the ‘Inform customer
What is the current objectivity of the ‘Assessment Details’ data of the ‘Inform customer of next steps’ function? What is the deviation of the current objectivity
Calculation Method
System Generated
396
of next steps’ function. from the desired one?
Believability To improve the believability of the ‘Assessment Details’ data of the ‘Inform customer of next steps’ function.
What is the current believability of the ‘Assessment Details’ data of the ‘Inform customer of next steps’ function? What is the deviation of the current believability from the desired one?
Calculation Method
System Generated
Reputation To improve the reputation of the ‘Assessment Details’ data of the ‘Inform customer of next steps’ function.
What is the current reputation of the ‘Assessment Details’ data of the ‘Inform customer of next steps’ function? What is the deviation of the current reputation from the desired one?
Calculation Method
System Generated
Relevancy To improve the relevancy of the ‘Assessment Details’ data of the ‘Inform customer of next steps’ function.
What is the current relevancy of the ‘Assessment Details’ data of the ‘Inform customer of next steps’ function? What is the deviation of the current relevancy from the desired one?
Assessment outcome is defined
Yes
Accessibility To improve the accessibility of the ‘Assessment Details’ data of the ‘Inform customer of next steps’ function.
What is the current accessibility of the ‘Assessment Details’ data of the ‘Inform customer of next steps’ function? What is the deviation of the current accessibility from the desired one?
Location of Data
= System A
Value-added To increase the value-added of the ‘Assessment Details’ data of the ‘Inform customer of next steps’ function.
What is the current added value of the ‘Assessment Details’ data of the ‘Inform customer of next steps’ function? What is the deviation of the current added value from the desired one?
Describes assessment outcome
Yes
Timeliness To improve the timeliness of the ‘Assessment Details’ data of the ‘Inform customer of next steps’ function.
What is the current timeliness of the ‘Assessment Details’ data of the ‘Inform customer of next steps’ function? What is the deviation of the current timeliness from the desired one?
Age of Data < 14 days
Completeness To improve the completeness of the ‘Assessment Details’ data of the ‘Inform customer of next steps’ function.
What is the current completeness of the ‘Assessment Details’ data of the ‘Inform customer of next steps’ function? What is the deviation of the current completeness from the desired one?
All fields present that describe assessment outcome
Yes
397
Amount of Data
To improve the amount of data of the ‘Assessment Details’ data of the ‘Inform customer of next steps’ function.
What is the current amount of data of the ‘Assessment Details’ data of the ‘Inform customer of next steps’ function? What is the deviation of the current amount of data from the desired one?
Enough data exists to describe assessment outcome
Yes
F12 - Finalise claim intake
Incident Details Accuracy To improve the accuracy of the ‘Incident Details’ data of the ‘Finalise claim intake’ function.
What is the current accuracy of the ‘Incident Details’ data of the ‘Finalise claim intake’ function? What is the deviation of the current accuracy from the desired one?
Subjective evaluation
n/a
Objectivity To improve the objectivity of the ‘Incident Details’ data of the ‘Finalise claim intake’ function.
What is the current objectivity of the ‘Incident Details’ data of the ‘Finalise claim intake’ function? What is the deviation of the current objectivity from the desired one?
Caller witnessed incident?
Yes
Corroborating witnesses exist?
Yes
Believability To improve the believability of the ‘Incident Details’ data of the ‘Finalise claim intake’ function.
What is the current believability of the ‘Incident Details’ data of the ‘Finalise claim intake’ function? What is the deviation of the current believability from the desired one?
Caller witnessed incident?
Yes
Corroborating witnesses exist?
Yes
Reputation To improve the reputation of the ‘Incident Details’ data of the ‘Finalise claim intake’ function.
What is the current reputation of the ‘Incident Details’ data of the ‘Finalise claim intake’ function? What is the deviation of the current reputation from the desired one?
Caller witnessed incident?
Yes
Corroborating witnesses exist?
Yes
Accessibility To improve the accessibility of the ‘Incident Details’ data of
What is the current accessibility of the ‘Incident Details’ data of the ‘Finalise claim intake’ function? What is the
Location of Data
= System A
398
the ‘Finalise claim intake’ function.
deviation of the current accessibility from the desired one?
Relevancy To improve the relevancy of the ‘Incident Details’ data of the ‘Finalise claim intake’ function.
What is the current relevancy of the ‘Incident Details’ data of the ‘Finalise claim intake’ function? What is the deviation of the current relevancy from the desired one?
Motor vehicle incident related
Yes
Value-added To increase the value-added of the ‘Incident Details’ data of the ‘Finalise claim intake’ function.
What is the current added value of the ‘Incident Details’ data of the ‘Finalise claim intake’ function? What is the deviation of the current added value from the desired one?
Incident detail is descriptive
Yes
Security To improve the security of the ‘Incident Details’ data of the ‘Finalise claim intake’ function.
What is the current security of the ‘Incident Details’ data of the ‘Finalise claim intake’ function? What is the deviation of the current security from the desired one?
Is audited? Yes
Completeness To improve the completeness of the ‘Incident Details’ data of the ‘Finalise claim intake’ function.
What is the current completeness of the ‘Incident Details’ data of the ‘Finalise claim intake’ function? What is the deviation of the current completeness from the desired one?
All mandatory details exist
Yes
Amount of Data
To improve the amount of data of the ‘Incident Details’ data of the ‘Finalise claim intake’ function.
What is the current amount of data of the ‘Incident Details’ data of the ‘Finalise claim intake’ function? What is the deviation of the current amount of data from the desired one?
Enough data exists to define incident
Yes
Third Party Details
Accuracy To improve the accuracy of the ‘Third Party Details’ data of the ‘Finalise claim intake’ function.
What is the current accuracy of the ‘Third Party Details’ data of the ‘Finalise claim intake’ function? What is the deviation of the current accuracy from the desired one?
Subjective evaluation
n/a
Objectivity To improve the objectivity of the ‘Third Party Details’ data of the ‘Finalise claim intake’ function.
What is the current objectivity of the ‘Third Party Details’ data of the ‘Finalise claim intake’ function? What is the deviation of the current objectivity from the desired one?
Source of data
=Policyholder
399
Believability To improve the believability of the ‘Third Party Details’ data of the ‘Finalise claim intake’ function.
What is the current believability of the ‘Third Party Details’ data of the ‘Finalise claim intake’ function? What is the deviation of the current believability from the desired one?
Source of data
=Policyholder
Security To improve the security of the ‘Third Party Details’ data of the ‘Finalise claim intake’ function.
What is the current security of the ‘Third Party Details’ data of the ‘Finalise claim intake’ function? What is the deviation of the current security from the desired one?
Source of data
=Policyholder
Accessibility To improve the accessibility of the ‘Third Party Details’ data of the ‘Finalise claim intake’ function.
What is the current accessibility of the ‘Third Party Details’ data of the ‘Finalise claim intake’ function? What is the deviation of the current accessibility from the desired one?
Storage Method
=electronic
Relevancy To improve the relevancy of the ‘Third Party Details’ data of the ‘Finalise claim intake’ function.
What is the current relevancy of the ‘Third Party Details’ data of the ‘Finalise claim intake’ function? What is the deviation of the current relevancy from the desired one?
Are details confirmed
Yes
Value-added To increase the value-added of the ‘Third Party Details’ data of the ‘Finalise claim intake’ function.
What is the current added value of the ‘Third Party Details’ data of the ‘Finalise claim intake’ function? What is the deviation of the current added value from the desired one?
Describes third party details
Yes
Completeness To improve the completeness of the ‘‘Third Party Details’ data of the ‘Finalise claim intake’ function.
What is the current completeness of the ‘Third Party Details’ data of the ‘Finalise claim intake’ function? What is the deviation of the current completeness from the desired one?
All fields present that describe third party
Yes
Amount of Data
To improve the amount of data of the ‘Third Party Details’ data of the ‘Finalise claim intake’ function.
What is the current amount of data of the ‘Third Party Details’ data of the ‘Finalise claim intake’ function? What is the deviation of the current amount of data from the desired one?
Enough data exists to describe third party
Yes
Third Party Vehicle Details -
Accessibility To improve the accessibility of the ‘Third
What is the current accessibility of the ‘Third Party Vehicles Details - Damage’
Storage Method
= electronic
400
Damage Party Vehicle Details - Damage’ data of the ‘Finalise claim intake’ function.
data of the ‘Finalise claim intake’ function? What is the deviation of the current accessibility from the desired one?
Relevancy To improve the relevancy of the ‘Third Party Vehicle Details - Damage’ data of the ‘Finalise claim intake’ function.
What is the current relevancy of the ‘Third Party Vehicles Details - Damage’ data of the ‘Finalise claim intake’ function? What is the deviation of the current relevancy from the desired one?
Damage described
Yes
Security To increase the security of the ‘Third Party Vehicle Details - Damage’ data of the ‘Finalise claim intake’ function.
What is the current security of the ‘Third Party Vehicles Details - Damage’ data of the ‘Finalise claim intake’ function? What is the deviation of the current security from the desired one?
Is audited Yes
Timeliness To improve the timeliness of the ‘Third Party Vehicle Details - Damage’ data of the ‘Finalise claim intake’ function.
What is the current timeliness of the ‘Third Party Vehicles Details - Damage’ data of the ‘Finalise claim intake’ function? What is the deviation of the current timeliness from the desired one?
Time since incident
< 14 days
Claim Services Accuracy To improve the accuracy of the ‘Claim Services’ data of the ‘Finalise claim intake’ function.
What is the current accuracy of the ‘Claim Services’ data of the ‘Finalise claim intake’ function? What is the deviation of the current accuracy from the desired one?
Subjective evaluation
n/a
Objectivity To improve the objectivity of the ‘Claim Services’ data of the ‘Finalise claim intake’ function.
What is the current objectivity of the ‘Claim Services’ data of the ‘Finalise claim intake’ function? What is the deviation of the current objectivity from the desired one?
Source of Data
Manual Selection
Believability To improve the believability of the ‘Claim Services’ data of the ‘Finalise claim intake’ function.
What is the current believability of the ‘Claim Services’ data of the ‘Finalise claim intake’ function? What is the deviation of the current believability from the desired one?
Source of Data
Manual Selection
401
Reputation To improve the reputation of the ‘Claim Services’ data of the ‘Finalise claim intake’ function.
What is the current reputation of the ‘Claim Services’ data of the ‘Finalise claim intake’ function? What is the deviation of the current reputation from the desired one?
Source of Data
Manual Selection
Accessibility To improve the accessibility of the ‘Claim Services’ data of the ‘Finalise claim intake’ function.
What is the current accessibility of the ‘Claim Services’ data of the ‘Finalise claim intake’ function? What is the deviation of the current accessibility from the desired one?
Storage method
Electronic
Relevancy To improve the relevancy of the ‘Claim Services’ data of the ‘Finalise claim intake’ function.
What is the current relevancy of the ‘Claim Services’ data of the ‘Finalise claim intake’ function? What is the deviation of the current relevancy from the desired one?
Claim service are defined
Yes
Value-added To increase the value added of the ‘Claim Services’ data of the ‘Finalise claim intake’ function.
What is the current value added of the ‘Claim Services’ data of the ‘Finalise claim intake’ function? What is the deviation of the current value added from the desired one?
Claim services are defined
Yes
Timeliness To increase the timeliness of the ‘Claim Services’ data of the ‘Finalise claim intake’ function.
What is the current timeliness of the ‘Claim Services’ data of the ‘Finalise claim intake’ function? What is the deviation of the current timeliness from the desired one?
Age of Data < 14 days
Completeness To improve the completeness of the ‘Claim Services’ data of the ‘Finalise claim intake’ function.
What is the current completeness of the ‘Claim Services’ data of the ‘Finalise claim intake’ function? What is the deviation of the current completeness from the desired one?
All fields present that describe claim services
Yes
Amount of Data
To improve the amount of data of the ‘Claim Services’ data of the ‘Finalise claim intake’ function.
What is the current amount of data of the ‘Claim Services’ data of the ‘Finalise claim intake’ function? What is the deviation of the current amount of data from the desired one?
Enough data exists to describe claim services
Yes
402
Assessment Details
Accuracy To improve the accuracy of the ‘Assessment Details’ data of the ‘Finalise claim intake’ function.
What is the current accuracy of the ‘Assessment Details’ data of the ‘Finalise claim intake’ function? What is the deviation of the current accuracy from the desired one?
Subjective evaluation
n/a
Objectivity To improve the objectivity of the ‘Assessment Details’ data of the ‘Finalise claim intake’ function.
What is the current objectivity of the ‘Assessment Details’ data of the ‘Finalise claim intake’ function? What is the deviation of the current objectivity from the desired one?
Calculation Method
System generated
Believability To improve the believability of the ‘Assessment Details’ data of the ‘Finalise claim intake’ function.
What is the current believability of the ‘Assessment Details’ data of the ‘Finalise claim intake’ function? What is the deviation of the current believability from the desired one?
Calculation Method
System generated
Reputation To improve the reputation of the ‘Assessment Details’ data of the ‘Finalise claim intake’ function.
What is the current reputation of the ‘Assessment Details’ data of the ‘Finalise claim intake’ function? What is the deviation of the current reputation from the desired one?
Calculation Method
System generated
Accessibility To improve the accessibility of the ‘Assessment Details’ data of the ‘Finalise claim intake’ function.
What is the current accessibility of the ‘Assessment Details’ data of the ‘Finalise claim intake’ function? What is the deviation of the current accessibility from the desired one?
Location of Data
= System A
Relevancy To improve the relevancy of the ‘Assessment Details’ data of the ‘Finalise claim intake’ function.
What is the current relevancy of the ‘Assessment Details’ data of the ‘Finalise claim intake’ function? What is the deviation of the current relevancy from the desired one?
Assessment is defined
Yes
Value-added To increase the value-added of the ‘Assessment Details’ data of the ‘Finalise claim intake’ function.
What is the current added value of the ‘Assessment Details’ data of the ‘Finalise claim intake’ function? What is the deviation of the current added value from the desired one?
Describes assessment outcome
Yes
Timeliness To increase timeliness of the ‘Assessment Details’
What is the current timeliness of the ‘Assessment Details’ data of the ‘Finalise
Age of Data < 14 days
403
data of the ‘Finalise claim intake’ function.
claim intake’ function? What is the deviation of the current timeliness from the desired one?
Completeness To improve the completeness of the ‘Assessment Details’ data of the ‘Finalise claim intake’ function.
What is the current completeness of the ‘Assessment Details’ data of the ‘Finalise claim intake’ function? What is the deviation of the current completeness from the desired one?
All fields present that describe assessment outcome
Yes
Amount of Data
To improve the amount of data of the ‘Assessment Details’ data of the ‘Finalise claim intake’ function.
What is the current amount of data of the ‘Assessment Details’ data of the ‘Finalise claim intake’ function? What is the deviation of the current amount of data from the desired one?
Enough data exists to describe assessment outcome
Yes
Claim Action Accuracy To improve the accuracy of the ‘Claim Action’ data of the ‘Finalise claim intake’ function.
What is the current accuracy of the ‘Claim Action’ data of the ‘Finalise claim intake’ function? What is the deviation of the current accuracy from the desired one?
Subjective evaluation
n/a
Objectivity To improve the objectivity of the ‘Claim Action’ data of the ‘Finalise claim intake’ function.
What is the current objectivity of the ‘Claim Action’ data of the ‘Finalise claim intake’ function? What is the deviation of the current objectivity from the desired one?
Calculation Method
System Generated
Believability To improve the believability of the ‘Claim Action’ data of the ‘Finalise claim intake’ function.
What is the current believability of the ‘Claim Action’ data of the ‘Finalise claim intake’ function? What is the deviation of the current believability from the desired one?
Calculation Method
System Generated
Reputation To improve the reputation of the ‘Claim Action’ data of the ‘Finalise claim intake’ function.
What is the current reputation of the ‘Claim Action’ data of the ‘Finalise claim intake’ function? What is the deviation of the current reputation from the desired one?
Calculation Method
System Generated
Accessibility To improve the accessibility of the ‘Claim Action’ data of the ‘Finalise claim intake’
What is the current accessibility of the ‘Claim Action’ data of the ‘Finalise claim intake’ function? What is the deviation of the current accessibility from the desired
Storage Method
= electronic
404
function. one?
Relevancy To improve the relevancy of the ‘Claim Action’ data of the ‘Finalise claim intake’ function.
What is the current relevancy of the ‘Claim Action’ data of the ‘Finalise claim intake’ function? What is the deviation of the current relevancy from the desired one?
Claim action is described
Yes
Value-added To increase the value-added of the ‘Claim Action’ data of the ‘Finalise claim intake’ function.
What is the current added value of the ‘Claim Action’ data of the ‘Finalise claim intake’ function? What is the deviation of the current added value from the desired one?
Claim action is described
Yes
Security To improve the security of the ‘Claim Action’ data of the ‘Finalise claim intake’ function.
What is the current security the ‘Claim Action’ data of the ‘Finalise claim intake’ function? What is the deviation of the current security from the desired one?
Is audited Yes
Timeliness To improve the timeliness of the ‘Claim Action’ data of the ‘Finalise claim intake’ function.
What is the current timeliness the ‘Claim Action’ data of the ‘Finalise claim intake’ function? What is the deviation of the current timeliness from the desired one?
Time since incident
< 14 days
Completeness To improve the completeness of the ‘Claim Action’ data of the ‘Finalise claim intake’ function.
What is the current completeness of the ‘Claim Action’ data of the ‘Finalise claim intake’ function? What is the deviation of the current completeness from the desired one?
All fields present that describe claim action
Yes
Amount of Data
To improve the amount of data of the ‘Claim Action’ data of the ‘Finalise claim intake’ function.
What is the current amount of data of the ‘Claim Action’ data of the ‘Finalise claim intake’ function? What is the deviation of the current amount of data from the desired one?
Enough data exists to describe claim action
Yes
405
Appendix C.8 Human Resource Measurement Model
Organisation A Human Resource Measurement Model
Functions Resource Quality Characteristics
Soft Goals Question Metric Threshold Value
F1 - Obtain policy details and validate caller (authorised to lodge)
Claims Processor
Domain Knowledge
To improve the domain knowledge of the Claims Processor performing the ‘Obtain policy details and validate caller’ function.
What is the current domain knowledge of the Claims Processor? What is the deviation of the current domain knowledge from the desired one?
Customer systems knowledge level (none, basic, intermediate, expert)
>= intermediate
Communication Skill
To improve the communication skill of the Claims Processor performing the ‘Obtain policy details and validate caller’ function.
What are the communication skills of the Claims Processor? What is the deviation of the communication skills of the Claims Processor to the desired one?
Listening skills (poor, average, good)
>= average
F2 - Validate Policy Claims Processor
Domain Knowledge
To improve the domain knowledge of the Claims Processor performing the ‘Validate policy’ function.
What is the current domain knowledge of the Claims Processor? What is the deviation of the current domain knowledge from the desired one?
Policy validation knowledge level (none, basic, intermediate, expert)
>= intermediate
Communication Skill
To improve the communication skill of the Claims Processor performing the ‘Validate policy’ function.
What are the communication skills of the Claims Processor? What is the deviation of the communication skills of the Claims Processor to the desired one?
Listening skills (poor, average, good)
>= average
F3 - Capture incident details
Claims Processor
Domain Knowledge
To improve the domain knowledge of the Claims Processor performing the ‘Capture incident details’
What is the current domain knowledge of the Claims Processor? What is the deviation of the current domain
Claims systems knowledge level (none, basic, intermediate,
>= intermediate
406
function. knowledge from the desired one?
expert)
Data capture methods knowledge level (none, basic, intermediate, expert)
>= intermediate
Experience To increase the experience of the Claims Processor performing the ‘Capture incident details’ function.
What is the current experience of the Claims Processor? What is the deviation of the current experience of the Claims Processor to the desired one?
Data entry experience
> 2 years
Communication Skill
To improve the communication skill of the Claims Processor performing the ‘Capture incident details’ function.
What are the communication skills of the Claims Processor? What is the deviation of the communication skills of the Claims Processor to the desired one?
Listening skills (poor, average, good)
>= average
F4 - Validate incident coverage
Claims Processor
Domain Knowledge
To improve the domain knowledge of the Claims Processor performing the ‘Validate incident coverage’ function.
What is the current domain knowledge of the Claims Processor? What is the deviation of the current domain knowledge from the desired one?
PDS knowledge level (none, basic, intermediate, expert)
>= intermediate
Experience To increase the experience of the Claims Processor performing the ‘Validate incident coverage’ function.
What is the current experience of the Claims Processor? What is the deviation of the current experience of the Claims Processor to the desired one?
Dealing with difficult people experience
> 2 years
Communication Skill
To improve the communication skill of the Claims Processor performing the ‘Validate incident coverage’ function.
What are the communication skills of the Claims Processor? What is the deviation of the communication skills of the Claims Processor to the desired one?
Empathy skills (poor, average, good)
= good
F5 - Assess liability Claims Domain To improve the domain What is the current domain PDS knowledge >= intermediate
407
Processor Knowledge knowledge of the Claims Processor performing the ‘Assess liability’ function.
knowledge of the Claims Processor? What is the deviation of the current domain knowledge from the desired one?
level (none, basic, intermediate, expert)
Motor Vehicle road rules knowledge level (none, basic, intermediate, expert)
> expert
Experience To increase the experience of the Claims Processor performing the ‘Assess liability’ function.
What is the current experience of the Claims Processor? What is the deviation of the current experience of the Claims Processor to the desired one?
Dealing with difficult people experience
> 2 years
Communication Skill
To improve the communication skill of the Claims Processor performing the ‘Assess liability’ function.
What are the communication skills of the Claims Processor? What is the deviation of the communication skills of the Claims Processor to the desired one?
Empathy skills (poor, average, good)
= good
F6 - Capture loss and TP details
Claims Processor
Domain Knowledge
To improve the domain knowledge of the Claims Processor performing the ‘Capture loss and TP details’ function.
What is the current domain knowledge of the Claims Processor? What is the deviation of the current domain knowledge from the desired one?
Claims systems knowledge level (none, basic, intermediate, expert)
>= intermediate
Data capture methods knowledge level (none, basic, intermediate, expert)
>= intermediate
Experience To increase the experience of the Claims Processor performing the ‘Capture loss and TP details’ function.
What is the current experience of the Claims Processor? What is the deviation of the current experience of the Claims
Data entry experience
> 2 years
408
Processor to the desired one?
Communication Skill
To improve the communication skill of the Claims Processor performing the ‘Capture loss and TP details’ function.
What are the communication skills of the Claims Processor? What is the deviation of the communication skills of the Claims Processor to the desired one?
Listening skills (poor, average, good)
>= average
F7 - Assess excess Claims Processor
Domain Knowledge
To improve the domain knowledge of the Claims Processor performing the ‘Assess excess’ function.
What is the current domain knowledge of the Claims Processor? What is the deviation of the current domain knowledge from the desired one?
PDS knowledge level (none, basic, intermediate, expert)
>= intermediate
Experience To increase the experience of the Claims Processor performing the ‘Assess excess’ function.
What is the current experience of the Claims Processor? What is the deviation of the current experience of the Claims Processor to the desired one?
Dealing with difficult people experience
> 2 years
Communication Skill
To improve the communication skill of the Claims Processor performing the ‘Assess excess’ function.
What are the communication skills of the Claims Processor? What is the deviation of the communication skills of the Claims Processor to the desired one?
Empathy skills (poor, average, good)
= good
F8 - Assess pathing Claims Processor
Domain Knowledge
To improve the domain knowledge of the Claims Processor performing the ‘Assess pathing’ function.
What is the current domain knowledge of the Claims Processor? What is the deviation of the current domain knowledge from the desired one?
Assess pathing business rules knowledge level (none, basic, intermediate, expert)
>= intermediate
Communication Skill
To improve the communication skill of the Claims Processor performing the ‘Assess pathing’ function.
What are the communication skills of the Claims Processor? What is the deviation of the communication skills of the Claims Processor to the desired one?
Salesmanship skills (poor, average, good)
= good
F9 - Action hire car Claims Domain To improve the domain What is the current domain Hire car and >= intermediate
409
and towing (as appropriate)
Processor Knowledge knowledge of the Claims Processor performing the ‘Action hire car and towing’ function.
knowledge of the Claims Processor? What is the deviation of the current domain knowledge from the desired one?
towing business rules knowledge level (none, basic, intermediate, expert)
Communication Skill
To improve the communication skill of the Claims Processor performing the ‘Action hire car and towing’ function.
What are the communication skills of the Claims Processor? What is the deviation of the communication skills of the Claims Processor to the desired one?
Ability to clearly articulate conditions of hire (poor, average, good)
= good
F11 - Inform customer of next steps
Claims Processor
Domain Knowledge
To improve the domain knowledge of the Claims Processor performing the ‘Inform Customer of next steps’ function.
What is the current domain knowledge of the Claims Processor? What is the deviation of the current domain knowledge from the desired one?
Claims process knowledge level (none, basic, intermediate, expert)
>= intermediate
Communication Skill
To improve the communication skill of the Claims Processor performing the ‘Inform Customer of next steps’ function.
What are the communication skills of the Claims Processor? What is the deviation of the communication skills of the Claims Processor to the desired one?
Ability to clearly articulate next steps (poor, average, good)
= good
Salesmanship skills (poor, average, good)
= good
F12 - Finalise claim intake
N/A N/A N/A
410
Appendix C.9 Non-Human Resource Measurement Model
Organisation A – Non-Human Resource Measurement Model
Functions Resource Quality Characteristics
Soft Goals Question Metric Threshold Value
F1 - Obtain policy details and validate caller (authorised to lodge)
System A Suitability To improve the suitability of System A performing the ‘Obtain policy details and validate caller’ function.
What is the current suitability of the ‘Obtain policy details and validate caller’ function? What is the deviation of the current suitability from the desired one?
Are policy details obtained?
Yes
Is caller validated?
Yes
System A Reliability To improve the reliability of System A performing the ‘Obtain policy details and validate caller’ function.
What is the current reliability of the ‘Obtain policy details and validate caller’ function? What is the deviation of the current reliability from the desired one?
Percentage uptime (%)
> 99.995%
System A Productivity To increase the productivity of System A performing the ‘Obtain policy details and validate caller’ function.
What is the current productivity of the ‘Obtain policy details and validate caller’ function? What is the deviation of the current productivity from the desired one?
Task Time < 2 minutes
F2 - Validate Policy
System A Suitability To improve the suitability of System A performing the ‘Validate policy’ function.
What is the current suitability of the ‘Validate Policy’ function? What is the deviation of the current suitability from the desired one?
Is policy validated?
Yes
System A Reliability To improve the reliability of System A performing the ‘Validate policy’
What is the current reliability of the ‘Validate Policy’ function? What is the deviation of the
Percentage uptime (%)
> 99.995%
411
function. current reliability from the desired one?
System A Productivity To increase the productivity of System A performing the ‘Validate policy’ function.
What is the current productivity of the ‘Validate Policy’ function? What is the deviation of the current productivity from the desired one?
Task Time < 2 minutes
F3 - Capture incident details
System A Suitability To improve the suitability of System A performing the ‘Capture incident details’ function.
What is the current suitability of the ‘Capture incident details’ function? What is the deviation of the current suitability from the desired one?
Were incident details captured?
Yes
System A Understandability To improve the understandability of System A performing the ‘Capture incident details’ function.
What is the current understandability of the ‘Capture incident details’ function? What is the deviation of the current understandability from the desired one?
Is a ‘User Guide’ available?
Yes
Is ‘Help Documentation’ available?
Yes
System A Productivity To increase the productivity of System A performing the ‘Capture incident details’ function.
What is the current productivity of the ‘Capture incident details’ function? What is the deviation of the current productivity from the desired one?
Task Time < 5 minutes
F4 - Validate incident coverage
System A Accuracy To improve the accuracy of System A performing the ‘Validate incident coverage’ function.
What is the current accuracy of the ‘Validate incident coverage’ function? What is the deviation of the current accuracy from the desired one?
Subjective evaluation
n/a
System A Reliability To improve the reliability of System A performing the ‘Validate incident coverage’ function.
What is the current reliability of the ‘Validate incident coverage’ function? What is the deviation of the current reliability from the desired one?
Percentage uptime (%)
> 99.995%
System A Understandability To improve the What is the current Is a ‘User Guide’ Yes
412
understandability of System A performing the ‘Validate incident coverage’ function.
understandability of the ‘Validate incident coverage’ function? What is the deviation of the current understandability from the desired one?
available?
Is ‘Help Documentation’ available?
Yes
F5 - Assess liability
System A Accuracy To improve the accuracy of System A performing the ‘Assess liability’ function.
What is the current accuracy of the ‘Assess Liability’ function? What is the deviation of the current accuracy from the desired one?
Subjective evaluation
n/a
System A Reliability To improve the reliability of System A performing the ‘Assess liability’ function.
What is the current reliability of the ‘Assess Liability’ function? What is the deviation of the current reliability from the desired one?
Percentage uptime (%)
> 99.995 %
System A Robustness To improve the robustness of System A performing the ‘Assess liability’ function.
What is the current robustness of the ‘Assess Liability’ function? What is the deviation of the current robustness from the desired one?
Length of maximum tolerable outage (minutes)
< 10 minutes
Mean time between failures
> 20 days
F6 - Capture loss and TP details
System A Suitability To improve the suitability of System A performing the ‘Capture loss and TP details’ function.
What is the current suitability of the ‘Capture loss and TP details’ function? What is the deviation of the current suitability from the desired one?
Were loss and TP details captured?
Yes
System A Understandability To improve the understandability of System A performing the ‘Capture loss and TP details’ function.
What is the current understandability of the ‘Capture loss and TP detail’ function? What is the deviation of the current understandability from the desired one?
Is a ‘User Guide’ available?
Yes
413
Is ‘Help Documentation’ available?
Yes
System A Productivity To increase the productivity of System A performing the ‘Capture loss and TP details’ function.
What is the current productivity of the ‘Capture loss and TP detail’ function? What is the deviation of the current productivity from the desired one?
Task Time < 3 minutes
F7 - Assess excess
System A Accuracy To improve the accuracy of System A performing the ‘Assess excess’ function.
What is the current accuracy of the ‘Assess excess’ function? What is the deviation of the current accuracy from the desired one?
Subjective evaluation
n/a
System A Reliability To improve the reliability of System A performing the ‘Assess excess’ function.
What is the current reliability of the ‘Assess excess’ function? What is the deviation of the current reliability from the desired one?
Percentage uptime (%)
> 99.995%
System A Robustness To improve the robustness of System A performing the ‘Assess excess’ function.
What is the current robustness of the ‘Assess excess’ function? What is the deviation of the current robustness from the desired one?
Length of maximum tolerable outage (minutes)
< 10 minutes
Mean time between failures
> 20 days
F8 - Assess pathing
System A Accuracy To improve the accuracy of System A performing the ‘Assess pathing’ function.
What is the current accuracy of the ‘Assess pathing’ function? What is the deviation of the current accuracy from the desired one?
Subjective evaluation
n/a
System A Reliability To improve the reliability of System A performing the ‘Assess pathing’ function.
What is the current reliability of the ‘Assess pathing’ function? What is the deviation of the current reliability from the desired one?
Percentage uptime (%)
> 99.995%
System A Productivity To increase the What is the current productivity Task Time < 2 minutes
414
productivity of System A performing the ‘Assess pathing’ function.
of the ‘Assess pathing’ function? What is the deviation of the current productivity from the desired one?
F9 - Action hire car and towing (as appropriate)
System A Suitability To improve the suitability of System A performing the ‘Action hire car and towing’ function.
What is the current suitability of the ‘Action hire car and towing’ function? What is the deviation of the current suitability from the desired one?
Was hire car and towing actioned (if required)?
Yes
System A Understandability To improve the understandability of System A performing the ‘Action hire car and towing’ function.
What is the current understandability of the ‘Action hire car and towing’ function? What is the deviation of the current understandability from the desired one?
Is a ‘User Guide’ available?
Yes
Is ‘Help Documentation’ available?
Yes
System A Learnability To improve the learnability of System A performing the ‘Action hire car and towing’ function.
What is the current learnability of the ‘Action hire car and towing’ function? What is the deviation of the current learnability from the desired one?
Help Frequency < 2 per week
Is ‘Help Documentation’ available?
Yes
Is ‘Help Documentation’ easily accessible?
Yes
F10 - Add authorised parties (as appropriate)
System A Suitability To improve the suitability of System A performing the ‘Add authorised parties’ function.
What is the current suitability of the ‘Add authorised parties’ function? What is the deviation of the current suitability from the desired one?
Were authorised parties added (if required)?
Yes
System A Security To improve the security of System A performing the
What is the current security of the ‘Add authorised parties’
Authenticated access
Yes
415
‘Add authorised parties’ function.
function? What is the deviation of the current security from the desired one?
Authorised access
Yes
Audit trail Yes
System A Understandability To improve the understandability of System A performing the ‘Add authorised parties’ function.
What is the current understandability of the ‘Inform customer of next steps’ function? What is the deviation of the current understandability from the desired one?
Is a ‘User Guide’ available?
Yes
Is ‘Help Documentation’ available?
Yes
F11 - Inform customer of next steps
System A Suitability To improve the suitability of System A performing the ‘Inform customer of next steps’ function.
What is the current suitability of the ‘Inform customer of next steps’ function? What is the deviation of the current suitability from the desired one?
Was the customer informed of the next steps?
Yes
System A Accuracy To improve the accuracy of System A performing the ‘Inform customer of next steps’ function.
What is the current accuracy of the ‘Inform customer of next steps’ function? What is the deviation of the current accuracy from the desired one?
Subjective evaluation
n/a
System A Understandability To improve the understandability of System A performing the ‘Inform customer of next steps’ function.
What is the current understandability of the ‘Inform customer of next steps’ function? What is the deviation of the current understandability from the desired one?
Is a ‘User Guide’ available?
Yes
Is ‘Help Documentation’ available?
Yes
F12 - Finalise claim intake
System A Accuracy To improve the accuracy of System A performing the ‘Finalise claim intake’
What is the current accuracy of the ‘Finalise claim intake’ function? What is the deviation of
Subjective evaluation
n/a
416
function. the current accuracy from the desired one?
System A Reliability To improve the reliability of System A performing the ‘Finalise claim intake’ function.
What is the current reliability of the ‘Finalise claim intake’ function? What is the deviation of the current reliability from the desired one?
Percentage uptime (%)
> 99.995%
System A Effectiveness To improve the effectiveness of System A performing the ‘Finalise claim intake’ function.
What is the current effectiveness of the ‘Finalise claim intake’ function? What is the deviation of the current effectiveness from the desired one?
Subjective evaluation
n/a
417
QoBP Automation Tool
User Guide
418
Section 1: Using the QoBP Tool
Introduction The QoBP Automation Tool is designed to automate the generation of artefacts for the QoBP process. It is implemented in Microsoft Excel and uses XML files for data input. Tasks are automated using the VBA language.
Getting Started The first step in using the QoBP Automation Tool is to define the data. Data is categorised into two types: Foundation Data and Process Data. Foundation Data is the data that defines the QoBP framework and Process Data is data that defines a specific process. Data is defined in xml documents. See Section 2 for examples of the xml data.
Defining the foundation data The foundation data is the data that defines the QoBP quality framework. It includes the following:
Data XML File Name Description Functional Quality Characteristics
Qlist.xml Contains the functional quality characteristics of the QoBP model
Data Quality Characteristics DataQList.xml Contains the input and output data quality characteristics of the QoBP model
Non-human Quality Characteristics
NHQList.xml Contains the non-human quality characteristics of the QoBP model
Data Quality Characteristic Mapping
QualMap.xml Contains the mapping of functional quality characteristics to data input/output quality characteristics
Non-human Quality Characteristic Mapping
QualMapNH.xml Contains the mapping of functional quality characteristics to non-human quality characteristics.
Defining the process data
The process data is data that defines a specific process. It consists of 3 data types.
Data XML File Name Description Functions FuncList.xml Contains the functions of a specific process Input/Output data IOList.xml Contains the input and output data for each
function for a specific process Rating Procrate.xml Contains the top 3 quality characteristics for
each function for a specific process
419
Directory Structure
The QoBPTool can be located anywhere in the file system as long as the following sub directories exist in the same location.
Path Description \ Location of QoBPTool.xls \Input Contains 2 folder for the input data \Input\Foundation Contains the foundation xml input files (see above) \Input\Process Contains the process xml input files (see above) \Output Location of output xml files \Doco Contains documentation
Starting the tool
To start the QoBP Tool, open QoBPTool.xls in Microsoft Excel. Ensure that macros are enabled.
Navigating the tool
The QoBPTool spreadsheet consists of multiple worksheets. These can be selected by clicking on the tabs at the bottom of the screen. All the functions that are required to run the QoBP tool are available from the command worksheet.
420
The commands available from the Command Page are as follows:
Button Action Function Quality Char. Displays the function quality characteristics Data Quality Char. Displays the data quality characteristics Non-Human Quality Char. Displays the non-human quality characteristics Data Quality Mapping Displays the mappings between the function quality
characteristics and the data quality characteristics Non-Human Quality Mapping Displays the mappings between the function quality
characteristics and the non-human resource quality characteristics
Data Refresh Reloads the data from the xml files into the QoBP tool Process Ratings by Function Processes the ratings data for use by the artefact generation
functions Function Quality List Generates a list of the quality characteristics for all functions in
the process Function Softgoal Summary List Generates a list of the softgoals for each quality characteristic for
all functions in the process Data Input/Output Quality List Generates a list of quality characteristics for the data inputs and
outputs for each function based on the data quality mapping Data Input/Output Softgoal Summary List
Generates a list of the softgoals for each quality characteristic for the data inputs/outputs for all functions in the process
421
Softgoal Correlation Model Generate the Softgoal correlation model for the process Non-Human Resource Quality List
Generates a list of the quality characteristics for all non-human resources in the process based on the non-human resource mapping
Non-Human Resource Softgoal Summary List
Generates a list of the softgoals for each quality characteristic for the non-human resources for all functions in the process
QoBP Tool Process Flow
The basic steps required to run the tool are as follows:
1. Define the foundation data requirements and enter into the appropriate xml file as described in the table above and copy to the \Input\Foundation directory.
2. Define the process specific data requirements and enter into the appropriate xml file as described in the table above and copy to the \Input\Process directory.
3. Select the ‘Refresh Data’ button on the Command worksheet to update the data in the model. 4. Select the ‘Process Rating by Function’ button on the Command spreadsheet to update the
model with the appropriate functional quality characteristics. 5. Select the relevant button on the Command spreadsheet under the Function Artefacts, Data
Input/Output Artefacts or Non-Human Resource Artefacts Sections to produce the required artefact.
422
Section 2: Example XML Data
Process Specific Data
Function List – FuncList.xml <?xml version="1.0" encoding="UTF-8"?> <FUNCLIST> <TITLE>Function Listing</TITLE> <PROCESS ProcID="P1"> <FUNCTION ID="F1"> <NAME>Classify FSR</NAME> </FUNCTION> <FUNCTION ID="F2"> <NAME>Prioritise FSR</NAME> </FUNCTION> <FUNCTION ID="F3"> <NAME>Categorise FSR</NAME> </FUNCTION> <FUNCTION ID="F4"> <NAME>Assign FSR</NAME> </FUNCTION> </PROCESS> </FUNCLIST> Input/Output List – IOList.xml <?xml version="1.0" encoding="UTF-8"?> <IOList> <TITLE>Input/Outputs for Functions </TITLE> <FUNC ID="F1"> <DATAITEM Type="Input/Output"> <DATANAME>FSR</DATANAME> </DATAITEM> </FUNC> <FUNC ID="F2"> <DATAITEM Type="Input/Output"> <DATANAME>FSR</DATANAME> </DATAITEM> </FUNC> <FUNC ID="F3"> <DATAITEM Type="Input/Output"> <DATANAME>FSR</DATANAME> </DATAITEM> </FUNC> <FUNC ID="F4"> <DATAITEM Type="Input/Output"> <DATANAME>FSR</DATANAME> </DATAITEM> <DATAITEM Type="Output"> <DATANAME>Email Reciept</DATANAME>
423
</DATAITEM> </FUNC> </IOList> Ratings – ProcRate.xml <?xml version="1.0" encoding="UTF-8"?> <PROCRATE> <TITLE>Process Ratings</TITLE> <PROCRATING ID="F1"> <FIRST>Q2</FIRST> <SECOND>Q1</SECOND> <THIRD>Q7</THIRD> </PROCRATING> <PROCRATING ID="F2"> <FIRST>Q9</FIRST> <SECOND>Q1</SECOND> <THIRD>Q7</THIRD> </PROCRATING> <PROCRATING ID="F3"> <FIRST>Q9</FIRST> <SECOND>Q1</SECOND> <THIRD>Q7</THIRD> </PROCRATING> <PROCRATING ID="F4"> <FIRST>Q4</FIRST> <SECOND>Q2</SECOND> <THIRD>Q7</THIRD> </PROCRATING> </PROCRATE> Foundation Data Functional Quality Characteristics – Qlist.xml <?xml version="1.0" encoding="UTF-8"?> <QLIST> <TITLE>Quality Characteristics Listing</TITLE> <QGROUP QGROUPID="QG11"> <QCHAR ID="Q1"> <NAME>Suitability</NAME> </QCHAR> <QCHAR ID="Q2"> <NAME>Accuracy</NAME> </QCHAR> <QCHAR ID="Q3"> <NAME>Security</NAME> </QCHAR> <QCHAR ID="Q4"> <NAME>Reliability</NAME> </QCHAR>
424
<QCHAR ID="Q5"> <NAME>Understandability</NAME> </QCHAR> <QCHAR ID="Q6"> <NAME>Learnability</NAME> </QCHAR> <QCHAR ID="Q7"> <NAME>Time behaviour efficiency</NAME> </QCHAR> <QCHAR ID="Q8"> <NAME>Resource utilisation</NAME> </QCHAR> <QCHAR ID="Q9"> <NAME>Effectiveness</NAME> </QCHAR> <QCHAR ID="Q10"> <NAME>Productivity</NAME> </QCHAR> <QCHAR ID="Q11"> <NAME>Safety</NAME> </QCHAR> <QCHAR ID="Q12"> <NAME>Satisfaction</NAME> </QCHAR> <QCHAR ID="Q13"> <NAME>Robustness</NAME> </QCHAR> </QGROUP> </QLIST> Data Quality Characteristics – DataQList.xml ?xml version="1.0" encoding="UTF-8"?> <QLIST> <TITLE>Data Quality Characteristics Listing</TITLE> <QGROUP QGROUPID="QD01"> <QCHAR ID="D1"> <NAME>Accuracy</NAME> </QCHAR> <QCHAR ID="D2"> <NAME>Objectivity</NAME> </QCHAR> <QCHAR ID="D3"> <NAME>Believability</NAME> </QCHAR> <QCHAR ID="D4"> <NAME>Reputation</NAME> </QCHAR> <QCHAR ID="D5"> <NAME>Accessibility</NAME> </QCHAR> <QCHAR ID="D6">
425
<NAME>Security</NAME> </QCHAR> <QCHAR ID="D7"> <NAME>Relevency</NAME> </QCHAR> <QCHAR ID="D8"> <NAME>Value-added</NAME> </QCHAR> <QCHAR ID="D9"> <NAME>Timeliness</NAME> </QCHAR> <QCHAR ID="D10"> <NAME>Completeness</NAME> </QCHAR> <QCHAR ID="D11"> <NAME>Amount of Data</NAME> </QCHAR> <QCHAR ID="D12"> <NAME>Understandability</NAME> </QCHAR> <QCHAR ID="D13"> <NAME>Concise Representation</NAME> </QCHAR> <QCHAR ID="D14"> <NAME>Consistent Representation</NAME> </QCHAR> </QGROUP> </QLIST> Non-human Quality Characteristics – NHQlist.xml <?xml version="1.0" encoding="UTF-8"?> <QLIST> <TITLE>Non-Human Quality Characteristics Listing</TITLE> <QGROUP QGROUPID="QG11"> <QCHAR ID="N1"> <NAME>Suitability</NAME> </QCHAR> <QCHAR ID="N2"> <NAME>Accuracy</NAME> </QCHAR> <QCHAR ID="N3"> <NAME>Security</NAME> </QCHAR> <QCHAR ID="N4"> <NAME>Reliability</NAME> </QCHAR> <QCHAR ID="N5"> <NAME>Understandability</NAME> </QCHAR> <QCHAR ID="N6"> <NAME>Learnability</NAME>
426
</QCHAR> <QCHAR ID="N7"> <NAME>Time behaviour efficiency</NAME> </QCHAR> <QCHAR ID="N8"> <NAME>Resource utilisation</NAME> </QCHAR> <QCHAR ID="N9"> <NAME>Effectiveness</NAME> </QCHAR> <QCHAR ID="N10"> <NAME>Productivity</NAME> </QCHAR> <QCHAR ID="N11"> <NAME>Safety</NAME> </QCHAR> <QCHAR ID="N12"> <NAME>Satisfaction</NAME> </QCHAR> </QGROUP> </QLIST> Data Quality Characteristic Mapping – QualMap.xml <?xml version="1.0" encoding="UTF-8"?> <QUALMAP> <TITLE>Quality Mapping</TITLE> <FUNCQUAL ID="Q1"> <MAP1>D1</MAP1> <MAP1>D2</MAP1> <MAP1>D3</MAP1> <MAP1>D4</MAP1> <MAP1>D7</MAP1> <MAP1>D8</MAP1> <MAP1>D9</MAP1> <MAP1>D10</MAP1> <MAP1>D11</MAP1> </FUNCQUAL> <FUNCQUAL ID="Q2"> <MAP1>D1</MAP1> <MAP1>D2</MAP1> <MAP1>D3</MAP1> <MAP1>D4</MAP1> </FUNCQUAL> <FUNCQUAL ID="Q3"> <MAP1>D5</MAP1> <MAP1>D6</MAP1> </FUNCQUAL> <FUNCQUAL ID="Q4"> <MAP1>D5</MAP1> <MAP1>D7</MAP1> <MAP1>D8</MAP1>
427
<MAP1>D10</MAP1> <MAP1>D11</MAP1> </FUNCQUAL> <FUNCQUAL ID="Q5"> <MAP1>D1</MAP1> <MAP1>D2</MAP1> <MAP1>D3</MAP1> <MAP1>D4</MAP1> <MAP1>D7</MAP1> <MAP1>D8</MAP1> <MAP1>D9</MAP1> <MAP1>D10</MAP1> <MAP1>D11</MAP1> </FUNCQUAL> <FUNCQUAL ID="Q6"> <MAP1>D7</MAP1> <MAP1>D8</MAP1> <MAP1>D10</MAP1> <MAP1>D11</MAP1> </FUNCQUAL> <FUNCQUAL ID="Q7"> <MAP1>D12</MAP1> <MAP1>D13</MAP1> <MAP1>D14</MAP1> </FUNCQUAL> <FUNCQUAL ID="Q8"> <MAP1>D12</MAP1> <MAP1>D13</MAP1> <MAP1>D14</MAP1> </FUNCQUAL> <FUNCQUAL ID="Q9"> <MAP1>D5</MAP1> </FUNCQUAL> <FUNCQUAL ID="Q10"> <MAP1>D5</MAP1> <MAP1>D7</MAP1> <MAP1>D8</MAP1> <MAP1>D9</MAP1> <MAP1>D10</MAP1> </FUNCQUAL> <FUNCQUAL ID="Q11"> <MAP1>D1</MAP1> <MAP1>D2</MAP1> <MAP1>D3</MAP1> <MAP1>D4</MAP1> <MAP1>D7</MAP1> <MAP1>D8</MAP1> <MAP1>D9</MAP1> <MAP1>D10</MAP1> <MAP1>D11</MAP1> </FUNCQUAL> <FUNCQUAL ID="Q12"> <MAP1>D5</MAP1>
428
<MAP1>D8</MAP1> <MAP1>D11</MAP1> </FUNCQUAL> <FUNCQUAL ID="Q13"> <MAP1>D1</MAP1> <MAP1>D2</MAP1> <MAP1>D3</MAP1> <MAP1>D4</MAP1> <MAP1>D7</MAP1> <MAP1>D8</MAP1> <MAP1>D9</MAP1> <MAP1>D10</MAP1> <MAP1>D11</MAP1> </FUNCQUAL> </QUALMAP> Non-human Quality Characteristic Mapping – QualMapNH.xml <?xml version="1.0" encoding="UTF-8"?> <QUALMAP> <TITLE>Quality Mapping</TITLE> <FUNCQUAL ID="Q1"> <MAP1>N1</MAP1> </FUNCQUAL> <FUNCQUAL ID="Q2"> <MAP1>N2</MAP1> </FUNCQUAL> <FUNCQUAL ID="Q3"> <MAP1>N3</MAP1> </FUNCQUAL> <FUNCQUAL ID="Q4"> <MAP1>N4</MAP1> </FUNCQUAL> <FUNCQUAL ID="Q5"> <MAP1>N5</MAP1> </FUNCQUAL> <FUNCQUAL ID="Q6"> <MAP1>N6</MAP1> </FUNCQUAL> <FUNCQUAL ID="Q7"> <MAP1>N7</MAP1> </FUNCQUAL> <FUNCQUAL ID="Q8"> <MAP1>N8</MAP1> </FUNCQUAL> <FUNCQUAL ID="Q9"> <MAP1>N9</MAP1> </FUNCQUAL> <FUNCQUAL ID="Q10"> <MAP1>N10</MAP1> </FUNCQUAL> <FUNCQUAL ID="Q11">
429
<MAP1>N11</MAP1> </FUNCQUAL> <FUNCQUAL ID="Q12"> <MAP1>N12</MAP1> </FUNCQUAL> <FUNCQUAL ID="Q13"> <MAP1>N13</MAP1> </FUNCQUAL> </QUALMAP>
430
Appendix D
Action Research Organisation B
431
Appendix D.1 Functions Softgoal Model
Organisation B – Functions Softgoal Model
Functions Quality Characteristics Soft Goals
F1 - Enter request details into ITSM
Accuracy To improve the accuracy of the ‘Enter request details into ITSM’ function.
Reliability To improve the reliability of the ‘Enter request details into ITSM’ function.
Understandability To improve the understandability of the ‘Enter request details into ITSM’ function.
F2 - Calculate Costs Accuracy To improve the accuracy of the ‘Calculate costs’ function.
Time behaviour efficiency To increase the time behaviour efficiency of the ‘Calculate costs’ function.
Effectiveness To improve the effectiveness of the ‘Calculate costs’ function.
F3 - Review and rank the case - SMILE review form
Reliability To improve the reliability of the ‘Review and rank the case’ function.
Effectiveness To improve the effectiveness of the ‘Review and rank the case’ function.
Satisfaction To increase the satisfaction of the ‘Review and rank the case’ function.
F4 - Enter SMILE ranking into ITSM
Accuracy To improve the accuracy of the ‘Enter SMILE ranking into ITSM’ function.
Reliability To improve the reliability of the ‘Enter SMILE ranking into ITSM’ function.
Effectiveness To improve the effectiveness of the ‘Enter SMILE ranking into ITSM’ function.
F5 - Communicate to staff and clients
Reliability To improve the reliability of the ‘Communicate to staff and clients’ function.
Effectiveness To improve the effectiveness of the ‘Communicate to staff and clients’ function.
Satisfaction To increase the satisfaction of the ‘Communicate to staff and clients’ function.
F6 - Develop the change Suitability To improve the suitability of the ‘Develop the change’ function.
Effectiveness To improve the effectiveness of the ‘Develop the change’ function.
Productivity To increase the productivity of the ‘Develop the change’ function.
F7 - Conduct UAT Accuracy To improve the accuracy of the ‘Conduct UAT’ function.
Reliability To improve the reliability of the ‘Conduct UAT’ function.
Effectiveness To improve the effectiveness of the ‘Conduct UAT’ function.
F8 – Release Reliability To improve the reliability of the ‘Release’ function.
432
Time behaviour efficiency To increase the time behaviour efficiency of the ‘Release’ function.
Satisfaction To increase the satisfaction of the ‘Release’ function.
F9 - Conduct customer satisfaction survey
Accuracy To improve the accuracy of the ‘Conduct customer satisfaction survey’ function.
Reliability To improve the reliability of the ‘Conduct customer satisfaction survey’ function.
Satisfaction To increase the satisfaction of the ‘Conduct customer satisfaction survey’ function.
433
Appendix D.2 Input & Output Softgoal Model
Organisation B – Input & Output Softgoal Model
Function Input/Output Data
Quality Characteristics
Soft Goals
F1 - Enter request details into ITSM
Change Request Accuracy To improve the accuracy of the ‘Change Request’ data of the ‘Enter request details into ITSM’ function.
Objectivity To improve the objectivity of the ‘Change Request’ data of the ‘Enter request details into ITSM’ function.
Believability To improve the believability of the ‘Change Request’ data of the ‘Enter request details into ITSM’ function.
Reputation To improve the reputation of the ‘Change Request’ data of the ‘Enter request details into ITSM’ function.
Relevancy To improve the relevancy of the ‘Change Request’ data of the ‘Enter request details into ITSM’ function.
Value-added To increase the value-added of the ‘Change Request’ data of the ‘Enter request details into ITSM’ function.
Completeness To improve the completeness of the ‘Change Request’ data of the ‘Enter request details into ITSM’ function.
Amount of Data To improve the amount of data of the ‘Change Request’ data of the ‘Enter request details into ITSM’ function.
Timeliness To improve the timeliness of the ‘Change Request’ data of the ‘Enter request details into ITSM’ function.
Risk and Opportunity Assessment
Accuracy To improve the accuracy of the ‘Risk and Opportunity Assessment’ data of the ‘Enter request details into ITSM’ function.
Objectivity To improve the objectivity of the ‘Risk and Opportunity Assessment’ data of the ‘Enter request details into ITSM’ function.
Believability To improve the believability of the ‘Risk and Opportunity Assessment’ data of the ‘Enter request details into ITSM’ function.
Reputation To improve the reputation of the ‘Risk and Opportunity Assessment’ data of the ‘Enter request details into ITSM’ function.
Relevancy To improve the relevancy of the ‘Risk and Opportunity Assessment’ data of the ‘Enter request details into ITSM’ function.
Value-added To increase the value-added of the ‘Risk and
434
Opportunity Assessment’ data of the ‘Enter request details into ITSM’ function.
Completeness To improve the completeness of the ‘‘Risk and Opportunity Assessment’ data of the ‘Enter request details into ITSM’ function.
Amount of Data To improve the amount of data of the ‘Risk and Opportunity Assessment’ data of the ‘Enter request details into ITSM’ function.
Timeliness To improve the timeliness of the ‘Risk and Opportunity Assessment’ data of the ‘Enter request details into ITSM’ function.
RFC v1 Accuracy To improve the accuracy of the ‘RFC v1’ data of the ‘Enter request details into ITSM’ function.
Accessibility To improve the accessibility of the ‘RFC v1’ data of the ‘Enter request details into ITSM’ function.
Relevancy To improve the relevancy of the ‘RFC v1’ data of the ‘Enter request details into ITSM’ function.
Value-added To increase the value-added of the ‘RFC v1’ data of the ‘Enter request details into ITSM’ function.
Completeness To improve the completeness of the ‘RFC v1’ data of the ‘Enter request details into ITSM’ function.
Amount of Data To improve the amount of data of the ‘RFC v1’ data of the ‘Enter request details into ITSM’ function.
F2 - Calculate Costs RFC v1 Accuracy To improve the accuracy of the ‘RFC v1’ data of the ‘Calculate costs’ function.
Understandability To improve the understandability of the ‘RFC v1’ data of the ‘Calculate costs’ function.
Accessibility To improve the accessibility of the ‘RFC v1’ data of the ‘Calculate costs’ function.
RFC v2 Accuracy To improve the accuracy of the ‘RFC v2’ data of the ‘Calculate costs’ function.
Understandability To improve the understandability of the ‘RFC v2’ data of the ‘Calculate costs’ function.
Accessibility To improve the accessibility of the ‘RFC v2’ data of the ‘Calculate costs’ function.
Business Value Score
Accuracy To improve the accuracy of the ‘Business Value Score’ data of the ‘Calculate costs’ function.
Objectivity To improve the objectivity of the ‘Business Value Score’ data of the ‘Calculate costs’ function.
Believability To improve the believability of the ‘Business Value Score’ data of the ‘Calculate costs’ function.
Reputation To improve the reputation of the ‘Business Value Score’ data of the ‘Calculate costs’
435
function.
Understandability To improve the understandability of the ‘Business Value Score’ data of the ‘Calculate costs’ function.
Accessibility To improve the accessibility of the ‘Business Value Score’ data of the ‘Calculate costs’ function.
F3 - Review and rank the case - SMILE review form
RFC v2 Accessibility To improve the accessibility of the ‘RFC v2’ data of the ‘Review and rank the case’ function.
Relevancy To improve the relevancy of the ‘RFC v2’ data of the ‘Review and rank the case’ function.
Value-added To increase the value-added of the ‘RFC v2’ data of the ‘Review and rank the case’ function.
Completeness To improve the completeness of the ‘RFC v2’ data of the ‘Review and rank the case’ function.
Amount of Data To improve the amount of data of the ‘RFC v2’ data of the ‘Review and rank the case’ function.
Business Value Score
Accessibility To improve the accessibility of the ‘Business Value Score’ data of the ‘Review and rank the case’ function.
Relevancy To improve the relevancy of the ‘Business Value Score’ data of the ‘Review and rank the case’ function.
Value-added To increase the value-added of the ‘Business Value Score’ data of the ‘Review and rank the case’ function.
Completeness To improve the completeness of the ‘Business Value Score’ data of the ‘Review and rank the case’ function.
Amount of Data To improve the amount of data of the ‘Business Value Score’ data of the ‘Review and rank the case’ function.
Priority List Accessibility To improve the accessibility of the ‘Priority List’ data of the ‘Review and rank the case’ function.
Relevancy To improve the relevancy of the ‘Priority List’ data of the ‘Review and rank the case’ function.
Value-added To increase the value-added of the ‘Priority List’ data of the ‘Review and rank the case’ function.
Completeness To improve the completeness of the ‘Priority List’ data of the ‘Review and rank the case’ function.
Amount of Data To improve the amount of data of the ‘Priority List’ data of the ‘Review and rank the case’ function.
436
F4 - Enter SMILE ranking into ITSM
Priority List Accuracy To improve the accuracy of the ‘Priority List’ data of the ‘Enter SMILE ranking into ITSM’ function.
Objectivity To improve the objectivity of the ‘Priority List’ data of the ‘Enter SMILE ranking into ITSM’ function.
Believability To improve the believability of the ‘Priority List’ data of the ‘Enter SMILE ranking into ITSM’ function.
Reputation To improve the reputation of the ‘Priority List’ data of the ‘Enter SMILE ranking into ITSM’ function.
Accessibility To improve the accessibility of the ‘Priority List’ data of the ‘Enter SMILE ranking into ITSM’ function.
Relevancy To improve the relevancy of the ‘Priority List’ data of the ‘Enter SMILE ranking into ITSM’ function.
Value-added To increase the value-added of the ‘Priority List’ data of the ‘Enter SMILE ranking into ITSM’ function.
Completeness To improve the completeness of the ‘Priority List’ data of the ‘Enter SMILE ranking into ITSM’ function.
Amount of Data To improve the amount of data of the ‘Priority List’ data of the ‘Enter SMILE ranking into ITSM’ function.
F5 - Communicate to staff and clients
Priority List Accessibility To improve the accessibility of the ‘Priority List’ data of the ‘Communicate to staff and clients’ function.
Relevancy To improve the relevancy of the ‘Priority List’ data of the ‘Communicate to staff and clients’ function.
Value-added To increase the value-added of the ‘Priority List’ data of the ‘Communicate to staff and clients’ function.
Completeness To improve the completeness of the ‘Priority List’ data of the ‘Communicate to staff and clients’ function.
Amount of Data To improve the amount of data of the ‘Priority List’ data of the ‘Communicate to staff and clients’ function.
F6 - Develop the change
RFC v2 Accuracy To improve the accuracy of the ‘RFC v2’ data of the ‘Develop the change’ function.
Relevancy To improve the relevancy of the ‘RFC v2’ data of the ‘Develop the change’ function.
Value-added To increase the value-added of the ‘RFC v2’ data of the ‘Develop the change’ function.
Timeliness To improve the timeliness of the ‘RFC v2’ data of the ‘Develop the change’ function.
Completeness To improve the completeness of the ‘RFC v2’ data of the ‘Develop the change’ function.
437
Amount of Data To improve the amount of data of the ‘RFC v2’ data of the ‘Develop the change’ function.
Accessibility To improve the accessibility of the ‘RFC v2’ data of the ‘Develop the change’ function.
Change Accuracy To improve the accuracy of the ‘Change’ data of the ‘Develop the change’ function.
Objectivity To improve the objectivity of the ‘Change’ data of the ‘Develop the change’ function.
Believability To improve the believability of the ‘Change’ data of the ‘Develop the change’ function.
Reputation To improve the reputation of the ‘Change’ data of the ‘Develop the change’ function.
Relevancy To improve the relevancy of the ‘Change’ data of the ‘Develop the change’ function.
Value-added To increase the value-added of the ‘Change’ data of the ‘Develop the change’ function.
Timeliness To improve the timeliness of the ‘Change’ data of the ‘Develop the change’ function.
Completeness To improve the completeness of the ‘Change’ data of the ‘Develop the change’ function.
Amount of Data To improve the amount of data of the ‘Change’ data of the ‘Develop the change’ function.
Accessibility To improve the accessibility of the ‘Change’ data of the ‘Develop the change’ function.
F7 - Conduct UAT Change Accuracy To improve the accuracy of the ‘Change’ data of the ‘Conduct UAT’ function.
Objectivity To improve the objectivity of the ‘Change’ data of the ‘Conduct UAT’ function.
Believability To improve the believability of the ‘Change’ data of the ‘Conduct UAT’ function.
Reputation To improve the reputation of the ‘Change’ data of the ‘Conduct UAT’ function.
Accessibility To improve the accessibility of the ‘Change’ data of the ‘Conduct UAT’ function.
Relevancy To improve the relevancy of the ‘Change’ data of the ‘Conduct UAT’ function.
Value-added To increase the value-added of the ‘Change’ data of the ‘Conduct UAT’ function.
Completeness To improve the completeness of the ‘Change’ data of the ‘Conduct UAT’ function.
Amount of Data To improve the amount of data of the ‘Change’ data of the ‘Conduct UAT’ function.
Signed off change Accuracy To improve the accuracy of the ‘Signed off change’ data of the ‘Conduct UAT’ function.
Objectivity To improve the objectivity of the ‘Signed off change’ data of the ‘Conduct UAT’ function.
Believability To improve the believability of the ‘Signed off change’ data of the ‘Conduct UAT’ function.
Reputation To improve the reputation of the ‘Signed off change’ data of the ‘Conduct UAT’ function.
438
Accessibility To improve the accessibility of the ‘Signed off change’ data of the ‘Conduct UAT’ function.
Completeness To improve the completeness of the ‘Signed off change’ data of the ‘Conduct UAT’ function.
F8 - Release Signed off change Accessibility To improve the accessibility of the ‘Signed off change’ data of the ‘Release’ function.
Completeness To improve the completeness of the ‘Signed off change’ data of the ‘Release’ function.
F9 - Conduct customer satisfaction survey
Survey Result Accuracy To improve the accuracy of the ‘Survey Result’ data of the ‘Conduct customer satisfaction survey’ function.
Objectivity To improve the objectivity of the ‘Survey Result’ data of the ‘Conduct customer satisfaction survey’ function.
Believability To improve the believability of the ‘Survey Result’ data of the ‘Conduct customer satisfaction survey’ function.
Reputation To improve the reputation of the ‘Survey Result’ data of the ‘Conduct customer satisfaction survey’ function.
Accessibility To improve the accessibility of the ‘Survey Result’ data of the ‘Conduct customer satisfaction survey’ function.
Relevancy To improve the relevancy of the ‘Survey Result’ data of the ‘Conduct customer satisfaction survey’ function.
Value-added To increase the value-added of the ‘Survey Result’ data of the ‘Conduct customer satisfaction survey’ function.
Completeness To improve the completeness of the ‘Survey Result’ data of the ‘Conduct customer satisfaction survey’ function.
439
Appendix D.3 Human Resource Softgoal Model
Organisation B – Human Resource Softgoal Model
Functions Resource Quality Characteristics
Soft Goals
F1 - Enter request details into ITSM
Operations Relationship Manager (ORM)
Experience To improve the experience of the ORM performing the ‘Enter request details into ITSM’ function.
Time Management Efficiency
To improve the time management efficiency of the ORM performing the ‘Enter request details into ITSM’ function.
F2 - Calculate Costs Change Manager
Domain Knowledge
To improve the domain knowledge of the Change Manager performing the ‘Calculate Costs’ function.
Experience To improve the experience of the Change Manager performing the ‘Calculate Costs’ function.
Time Management Efficiency
To improve the time management efficiency of the Change Manager performing the ‘Calculate Costs’ function.
F3 - Review and rank the case - SMILE review form
SMILE review committee
Domain Knowledge
To improve the domain knowledge of the SMILE review committee performing the ‘Review and rank the case’ function.
Experience To improve the experience of the SMILE review committee performing the ‘Review and rank the case’ function.
Time Management Efficiency
To improve the time management efficiency of the SMILE review committee performing the ‘Review and rank the case’ function.
Communication Skill
To improve the communication skill of the SMILE review committee performing the ‘Review and rank the case’ function.
F4 - Enter SMILE ranking into ITSM
Operations Relationship Manager (ORM)
Experience To improve the experience of the ORM performing the ‘Enter SMILE ranking into ITSM’ function.
F5 - Communicate to staff and clients
Operations Relationship Manager (ORM)
Experience To improve the experience of the ORM performing the ‘Communicate to staff and clients’ function.
Time Management Efficiency
To improve the time management efficiency of the ORM performing the ‘Communicate to staff and clients’ function.
Communication Skill
To improve the communication skill of the ORM performing the ‘Communicate to staff and clients’ function.
440
F6 - Develop the change
IT Team Domain Knowledge
To improve the domain knowledge of the IT Team performing the ‘Develop the Change’ function.
Qualification To improve the qualification level of the IT Team performing the ‘Develop the change’ function.
Experience To improve the experience of the IT Team performing the ‘Develop the change’ function.
Time Management Efficiency
To improve the time management efficiency of the IT Team performing the ‘Develop the change’ function.
Communication Skill
To improve the communication skill of the IT Team performing the ‘Develop the change’ function.
F7 - Conduct UAT Business Team
Domain Knowledge
To improve the domain knowledge of the Business Team performing the ‘Conduct UAT’ function.
Experience To improve the experience of the Business Team performing the ‘Conduct UAT’ function.
Time Management Efficiency
To improve the time management efficiency of the Business Team performing the ‘Conduct UAT’ function.
Communication Skill
To improve the communication skill of the Business Team performing the ‘Conduct UAT’ function.
F8 - Release Release Manager
Time Management Efficiency
To improve the time management efficiency of the Release Manager performing the ‘Release’ function.
Communication Skill
To improve the communication skill of the Release Manager performing the ‘Release’ function.
441
Appendix D.4 Non-Human Resource Softgoal Model
Organisation B – Non-Human Resource Softgoal Model
Functions System Quality Characteristics
Soft Goals
F1 - Enter request details into ITSM
ITSM Accuracy To improve the accuracy of the ITSM system performing the ‘Enter request details into ITSM’ function.
Reliability To improve the reliability of the ITSM system performing the ‘Enter request details into ITSM’ function.
Understandability To improve the understandability of the ITSM system performing the ‘Enter request details into ITSM’ function.
F2 - Calculate Costs ITSM Accuracy To improve the accuracy of the ITSM system performing the ‘Calculate costs’ function.
Time behaviour efficiency
To increase the time behaviour efficiency of the ITSM system performing the ‘Calculate costs’ function.
Effectiveness To improve the effectiveness of the ITSM system performing the ‘Calculate costs’ function.
F3 - Review and rank the case - SMILE review form
ITSM Reliability To improve the reliability of the ITSM system performing the ‘Review and rank the case’ function.
Effectiveness To improve the effectiveness of the ITSM system performing the ‘Review and rank the case’ function.
Satisfaction To increase the satisfaction of the ITSM system performing the ‘Review and rank the case’ function.
F4 - Enter SMILE ranking into ITSM
ITSM Accuracy To improve the accuracy of the ITSM system performing the ‘Enter SMILE ranking into ITSM’ function.
Reliability To improve the reliability of the ITSM system performing the ‘Enter SMILE ranking into ITSM’ function.
Effectiveness To improve the effectiveness of the ITSM system performing the ‘Enter SMILE ranking into ITSM’ function.
442
Appendix D.5 Softgoal Correlation Model
Organisation B – Softgoal Correlation Model
Functions Input Output Function
Correlated Soft Goal
F8 - Release Signed off change F7 To improve the accuracy of the ‘Conduct UAT’ function.
To improve the reliability of the ‘Conduct UAT’ function. To improve the effectiveness of the ‘Conduct UAT’ function.
F7 - Conduct UAT Change F6 To improve the suitability of the ‘Develop the change’ function. To improve the effectiveness of the ‘Develop the change’ function.
To increase the productivity of the ‘Develop the change’ function. F6 - Develop the change
RFC v2 F2 To improve the accuracy of the ‘Calculate costs’ function.
To increase the time behaviour efficiency of the ‘Calculate costs’ function. To improve the effectiveness of the ‘Calculate costs’ function.
F5 - Communicate to staff and clients
Priority List F3 To improve the reliability of the ‘Review and rank the case’ function.
To improve the effectiveness of the ‘Review and rank the case’ function. To increase the satisfaction of the ‘Review and rank the case’ function.
F4 To improve the accuracy of the ‘Enter SMILE ranking into ITSM’ function. To improve the reliability of the ‘Enter SMILE ranking into ITSM’ function.
To improve the effectiveness of the ‘Enter SMILE ranking into ITSM’ function. F4 - Enter SMILE ranking into ITSM
Priority List F3 To improve the reliability of the ‘Review and rank the case’ function.
To improve the effectiveness of the ‘Review and rank the case’ function. To increase the satisfaction of the ‘Review and rank the case’ function.
443
F3 - Review and rank the case - SMILE review form
RFC v2 F2 To improve the accuracy of the ‘Calculate costs’ function.
To increase the time behaviour efficiency of the ‘Calculate costs’ function. To improve the effectiveness of the ‘Calculate costs’ function.
Business Value Score F2 To improve the accuracy of the ‘Calculate costs’ function.
To increase the time behaviour efficiency of the ‘Calculate costs’ function.
To improve the effectiveness of the ‘Calculate costs’ function. F2 To improve the accuracy of the ‘Calculate costs’ function.
To increase the time behaviour efficiency of the ‘Calculate costs’ function. To improve the effectiveness of the ‘Calculate costs’ function.
F2 - Calculate Costs RFC v1 F1 To improve the accuracy of the ‘Enter request details into ITSM’ function. To improve the reliability of the ‘Enter request details into ITSM’ function.
To improve the understandability of the ‘Enter request details into ITSM’ function.
444
Appendix D.6 Function Measurement Model
Organisation B – Function Measurement Model
Functions Quality Characteristics
Soft Goals Question Metric Threshold Value
F1 - Enter request details into ITSM
Accuracy To improve the accuracy of the ‘Enter request details into ITSM’ function.
What is the current accuracy of the ‘Enter request details into ITSM’ function? What is the deviation of the current accuracy from the desired one?
Subjective evaluation
n/a
Reliability To improve the reliability of the ‘Enter request details into ITSM’ function.
What is the current reliability of the ‘Enter request details into ITSM’ function? What is the deviation of the current reliability from the desired one?
Percentage uptime (%)
> 99 %
Understandability To improve the understandability of the ‘Enter request details into ITSM’ function.
What is the current understandability of the ‘Enter request details into ITSM’ function? What is the deviation of the current understandability from the desired one?
Is a ‘User Guide’ available?
Yes
Is ‘Help Documentation’ available?
Yes
F2 - Calculate Costs
Accuracy To improve the accuracy of the ‘Calculate costs’ function.
What is the current accuracy of the ‘Calculate Costs’ function? What is the deviation of the current accuracy from the desired one?
Subjective evaluation
n/a
Time behaviour efficiency
To increase the time behaviour efficiency of the ‘Calculate costs’ function.
What is the current time behaviour efficiency of the ‘Calculate Costs’ function? What is the deviation of the current time behaviour efficiency from the desired one?
Turnaround Time < 2 days
Waiting Time < 1 day
445
Effectiveness To improve the effectiveness of the ‘Calculate costs’ function.
What is the current effectiveness of the ‘Calculate Costs’ function? What is the deviation of the current effectiveness from the desired one?
Error Frequency < 4%
F3 - Review and rank the case - SMILE review form
Reliability To improve the reliability of the ‘Review and rank the case’ function.
What is the current reliability of the ‘Review and rank the case’ function? What is the deviation of the current reliability from the desired one?
Percentage uptime (%)
> 99%
Effectiveness To improve the effectiveness of the ‘Review and rank the case’ function.
What is the current effectiveness of the ‘Review and rank the case’ function? What is the deviation of the current effectiveness from the desired one?
Error Frequency < 4%
Satisfaction To increase the satisfaction of the ‘Review and rank the case’ function.
What is the current satisfaction of the ‘Review and rank the case’ function? What is the deviation of the current satisfaction from the desired one?
Satisfaction Scale (low, medium, high)
>= medium
F4 - Enter SMILE ranking into ITSM
Accuracy To improve the accuracy of the ‘Enter SMILE ranking into ITSM’ function.
What is the current accuracy of the ‘Enter SMILE ranking into ITSM’ function? What is the deviation of the current accuracy from the desired one?
Subjective evaluation
Yes
Reliability To improve the reliability of the ‘Enter SMILE ranking into ITSM’ function.
What is the current reliability of the ‘Enter SMILE ranking into ITSM’ function? What is the deviation of the current reliability from the desired one?
Percentage uptime (%)
> 99%
Effectiveness To improve the effectiveness of the ‘Enter SMILE ranking into ITSM’ function.
What is the current effectiveness of the ‘Enter SMILE ranking into ITSM’ function? What is the deviation of the current effectiveness from the desired one?
Error Frequency < 1%
F5 - Communicate to staff and clients
Reliability To improve the reliability of the ‘Communicate to staff and clients’ function.
What is the current reliability of the ‘Communicate to staff and clients’ function? What is the deviation of the current reliability from the
Written communication sent
Yes
446
desired one?
Effectiveness To improve the effectiveness of the ‘Communicate to staff and clients’ function.
What is the current effectiveness of the ‘Communicate to staff and clients’ function? What is the deviation of the current effectiveness from the desired one?
Error Frequency < 1%
Satisfaction To increase the satisfaction of the ‘Communicate to staff and clients’ function.
What is the current satisfaction of the ‘Communicate to staff and clients’ function? What is the deviation of the current satisfaction from the desired one?
Satisfaction Scale (low, medium, high)
>= medium
F6 - Develop the change
Suitability To improve the suitability of the ‘Develop the change’ function.
What is the current suitability of the ‘Communicate to staff and clients’ function? What is the deviation of the current suitability from the desired one?
Change was developed
Yes
Effectiveness To improve the effectiveness of the ‘Develop the change’ function.
What is the current effectiveness of the ‘Develop the change’ function? What is the deviation of the current effectiveness from the desired one?
Error Frequency < 2%
Productivity To increase the productivity of the ‘Develop the change’ function.
What is the current productivity of the ‘Develop the change’ function? What is the deviation of the current productivity from the desired one?
Days per Function Point
< 4
F7 - Conduct UAT
Accuracy To improve the accuracy of the ‘Conduct UAT’ function.
What is the current accuracy of the ‘Conduct UAT’ function? What is the deviation of the current accuracy from the desired one?
Subjective evaluation
n/a
Reliability To improve the reliability of the ‘Conduct UAT’ function.
What is the current reliability of the ‘Conduct UAT’ function? What is the deviation of the current reliability from the desired one?
UAT performed Yes
Effectiveness To improve the effectiveness of the ‘Conduct UAT’ function.
What is the current effectiveness of the ‘Conduct UAT’ function? What is the deviation of the current effectiveness from the desired one?
Error Frequency < 2%
F8 - Release Reliability To improve the reliability of the What is the current reliability of the Change Released Yes
447
‘Release’ function. ‘Release’ function? What is the deviation of the current reliability from the desired one?
Time behaviour efficiency
To increase the time behaviour efficiency of the ‘Release’ function.
What is the current time behaviour efficiency of the ‘Release’ function? What is the deviation of the current time behaviour efficiency from the desired one?
Turnaround Time < 1 week
Satisfaction To increase the satisfaction of the ‘Release’ function.
What is the current satisfaction of the ‘Release’ function? What is the deviation of the current satisfaction from the desired one?
Satisfaction Scale (low, medium, high)
>= medium
F9 - Conduct customer satisfaction survey
Accuracy To improve the accuracy of the ‘Conduct customer satisfaction survey’ function.
What is the current accuracy of the ‘Conduct customer satisfaction survey’ function? What is the deviation of the current accuracy from the desired one?
Subjective evaluation
n/a
Reliability To improve the reliability of the ‘Conduct customer satisfaction survey’ function.
What is the current reliability of the ‘Conduct customer satisfaction survey’ function? What is the deviation of the current reliability from the desired one?
Survey conducted Yes
Satisfaction To increase the satisfaction of the ‘Conduct customer satisfaction survey’ function.
What is the current satisfaction of the ‘Conduct customer satisfaction survey’ function? What is the deviation of the current satisfaction from the desired one?
Satisfaction Scale (low, medium, high)
>= medium
448
Appendix D.7 Input & Output Measurement Model
Organisation B – Input & Output Measurement Model
Function Input/Output Data
Quality Characteristics
Soft Goals Question accuracy Metric Threshold Value
F1 - Enter request details into ITSM
Change Request
Accuracy To improve the accuracy of the ‘Change Request’ data of the ‘Enter request details into ITSM’ function.
What is the current accuracy of the ‘Change Request’ data of the ‘Enter request details into ITSM’ function? What is the deviation of the current accuracy from the desired one?
Collection Method
Standard template
Objectivity To improve the objectivity of the ‘Change Request’ data of the ‘Enter request details into ITSM’ function.
What is the current objectivity of the ‘Change Request’ data of the ‘Enter request details into ITSM’ function? What is the deviation of the current objectivity from the desired one?
Collection Method
Standard template
Believability To improve the believability of the ‘Change Request’ data of the ‘Enter request details into ITSM’ function.
What is the current believability of the ‘Change Request’ data of the ‘Enter request details into ITSM’ function? What is the deviation of the current believability from the desired one?
Source of Data Key business stakeholder
Reputation To improve the reputation of the ‘Change Request’ data of the ‘Enter request details into ITSM’ function.
What is the current reputation of the ‘Change Request’ data of the ‘Enter request details into ITSM’ function? What is the deviation of the current reputation from the desired one?
Source of Data Key business stakeholder
Collection Method
Standard template
449
Relevancy To improve the relevancy of the ‘Change Request’ data of the ‘Enter request details into ITSM’ function.
What is the current relevancy of the ‘Change Request’ data of the ‘Enter request details into ITSM’ function? What is the deviation of the current relevancy from the desired one?
Is change related Yes
Value-added To increase the value-added of the ‘Change Request’ data of the ‘Enter request details into ITSM’ function.
What is the current value-added of the ‘Change Request’ data of the ‘Enter request details into ITSM’ function? What is the deviation of the current value-added from the desired one?
Descriptive (Yes/No)
Yes
Completeness To improve the completeness of the ‘Change Request’ data of the ‘Enter request details into ITSM’ function.
What is the current completeness of the ‘Change Request’ data of the ‘Enter request details into ITSM’ function? What is the deviation of the current completeness from the desired one?
Percentage of populated required fields
> 80%
Amount of Data To improve the amount of data of the ‘Change Request’ data of the ‘Enter request details into ITSM’ function.
What is the current amount of data of the ‘Change Request’ data of the ‘Enter request details into ITSM’ function? What is the deviation of the current amount of data from the desired one?
Enough data exists to describe vehicle damage
Yes
Timeliness To improve the timeliness of the ‘Change Request’ data of the ‘Enter request details into ITSM’ function.
What is the current timeliness of the ‘Change Request’ data of the ‘Enter request details into ITSM’ function? What is the deviation of the current timeliness from the desired one?
Age of Data < 2 months
Risk and Opportunity Assessment
Accuracy To improve the accuracy of the ‘Risk and Opportunity Assessment’ data of the ‘Enter request details into ITSM’ function.
What is the current accuracy of the ‘Risk and Opportunity Assessment’ data of the ‘Enter request details into ITSM’ function? What is the deviation of the current accuracy from the desired one?
Calculation method
Standard method
450
Objectivity To improve the objectivity of the ‘Risk and Opportunity Assessment’ data of the ‘Enter request details into ITSM’ function.
What is the current objectivity of the ‘Risk and Opportunity Assessment’ data of the ‘Enter request details into ITSM’ function? What is the deviation of the current objectivity from the desired one?
Source of Data Independent evaluation
Believability To improve the believability of the ‘Risk and Opportunity Assessment’ data of the ‘Enter request details into ITSM’ function.
What is the current believability of the ‘Risk and Opportunity Assessment’ data of the ‘Enter request details into ITSM’ function? What is the deviation of the current believability from the desired one?
Source of Data Independent evaluation
Reputation To improve the reputation of the ‘Risk and Opportunity Assessment’ data of the ‘Enter request details into ITSM’ function.
What is the current reputation of the ‘Risk and Opportunity Assessment’ data of the ‘Enter request details into ITSM’ function? What is the deviation of the current reputation from the desired one?
Source of Data Independent evaluation
Calculation method
Standard method
Relevancy To improve the relevancy of the ‘Risk and Opportunity Assessment’ data of the ‘Enter request details into ITSM’ function.
What is the current relevancy of the ‘Risk and Opportunity Assessment’ data of the ‘Enter request details into ITSM’ function? What is the deviation of the current relevancy from the desired one?
Defines risks and opportunities
Yes
Value-added To increase the value-added of the ‘Risk and Opportunity Assessment’ data of the ‘Enter request details into ITSM’ function.
What is the current value-added of the ‘Risk and Opportunity Assessment’ data of the ‘Enter request details into ITSM’ function? What is the deviation of the current value-added from the desired one?
Descriptive (Yes/No)
Yes
451
Completeness To improve the completeness of the ‘‘Risk and Opportunity Assessment’ data of the ‘Enter request details into ITSM’ function.
What is the current completeness of the ‘Risk and Opportunity Assessment’ data of the ‘Enter request details into ITSM’ function? What is the deviation of the current completeness from the desired one?
Percentage of populated required fields
= 100%
Amount of Data To improve the amount of data of the ‘Risk and Opportunity Assessment’ data of the ‘Enter request details into ITSM’ function.
What is the current amount of data of the ‘Risk and Opportunity Assessment’ data of the ‘Enter request details into ITSM’ function? What is the deviation of the current amount of data from the desired one?
Enough data exists to describe risks and opportunities
Yes
Timeliness To improve the timeliness of the ‘Risk and Opportunity Assessment’ data of the ‘Enter request details into ITSM’ function.
What is the current timeliness of the ‘Risk and Opportunity Assessment’ data of the ‘Enter request details into ITSM’ function? What is the deviation of the current timeliness from the desired one?
Age of Data < 2 months
RFC v1 Accuracy To improve the accuracy of the ‘RFC v1’ data of the ‘Enter request details into ITSM’ function.
What is the current accuracy of the ‘RFCv1’ data of the ‘Enter request details into ITSM’ function? What is the deviation of the current accuracy from the desired one?
Source of Data Standard template
Accessibility To improve the accessibility of the ‘RFC v1’ data of the ‘Enter request details into ITSM’ function.
What is the current accessibility of the ‘RFCv1’ data of the ‘Enter request details into ITSM’ function? What is the deviation of the current accessibility from the desired one?
Location of Data ITSM
Relevancy To improve the relevancy of the ‘RFC v1’ data of the ‘Enter request details into ITSM’ function.
What is the current relevancy of the ‘RFCv1’ data of the ‘Enter request details into ITSM’ function? What is the deviation of the current relevancy from the
Describes required change
Yes
452
desired one?
Value-added To increase the value-added of the ‘RFC v1’ data of the ‘Enter request details into ITSM’ function.
What is the current value-added of the ‘RFCv1’ data of the ‘Enter request details into ITSM’ function? What is the deviation of the current value-added from the desired one?
Descriptive (Yes/No)
Yes
Completeness To improve the completeness of the ‘RFC v1’ data of the ‘Enter request details into ITSM’ function.
What is the current completeness of the ‘RFCv1’ data of the ‘Enter request details into ITSM’ function? What is the deviation of the current completeness from the desired one?
Percentage of populated required fields
> 90%
Amount of Data To improve the amount of data of the ‘RFC v1’ data of the ‘Enter request details into ITSM’ function.
What is the current amount of data of the ‘RFCv1’ data of the ‘Enter request details into ITSM’ function? What is the deviation of the current amount of data from the desired one?
Enough data exists to describe risks and opportunities
Yes
F2 - Calculate Costs
RFC v1 Accuracy To improve the accuracy of the ‘RFC v1’ data of the ‘Calculate costs’ function.
What is the current accuracy of the ‘RFCv1’ data of the ‘Calculate costs’ function? What is the deviation of the current accuracy from the desired one?
Source of Data ITSM
Understandability To improve the understandability of the ‘RFC v1’ data of the ‘Calculate costs’ function.
What is the current understandability of the ‘RFCv1’ data of the ‘Calculate costs’ function? What is the deviation of the current understandability from the desired one?
Required change description is well described (Yes/No)
Yes
Accessibility To improve the accessibility of the ‘RFC v1’ data of the ‘Calculate costs’ function.
What is the current accessibility of the ‘RFCv1’ data of the ‘Calculate costs’ function? What is the deviation of the current accessibility from the desired one?
Location of Data ITSM
453
RFC v2 Accuracy To improve the accuracy of the ‘RFC v2’ data of the ‘Calculate costs’ function.
What is the current accuracy of the ‘RFCv2’ data of the ‘Calculate costs’ function? What is the deviation of the current accuracy from the desired one?
Subjective evaluation
n/a
Understandability To improve the understandability of the ‘RFC v2’ data of the ‘Calculate costs’ function.
What is the current understandability of the ‘RFCv2’ data of the ‘Calculate costs’ function? What is the deviation of the current understandability from the desired one?
Required change description is well described (Yes/No)
Yes
Accessibility To improve the accessibility of the ‘RFC v2’ data of the ‘Calculate costs’ function.
What is the current accessibility of the ‘RFCv2’ data of the ‘Calculate costs’ function? What is the deviation of the current accessibility from the desired one?
Location of Data ITSM
Business Value Score
Accuracy To improve the accuracy of the ‘Business Value Score’ data of the ‘Calculate costs’ function.
What is the current accuracy of the ‘Business Value Score’ data of the ‘Calculate costs’ function? What is the deviation of the current accuracy from the desired one?
Calculation method
Standard
Objectivity To improve the objectivity of the ‘Business Value Score’ data of the ‘Calculate costs’ function.
What is the current objectivity of the ‘Business Value Score’ data of the ‘Calculate costs’ function? What is the deviation of the current objectivity from the desired one?
Calculation method
Standard
Believability To improve the believability of the ‘Business Value Score’ data of the ‘Calculate costs’ function.
What is the current believability of the ‘Business Value Score’ data of the ‘Calculate costs’ function? What is the deviation of the current believability from the desired one?
Calculation method
Standard
Reputation To improve the reputation of the ‘Business Value Score’ data of the
What is the current reputation of the ‘Business Value Score’ data of the ‘Calculate costs’ function?
Calculation method
Standard
454
‘Calculate costs’ function. What is the deviation of the current reputation from the desired one?
Understandability To improve the understandability of the ‘Business Value Score’ data of the ‘Calculate costs’ function.
What is the current understandability of the ‘Business Value Score’ data of the ‘Calculate costs’ function? What is the deviation of the current understandability from the desired one?
Required change description is well described (Yes/No)
Yes
Accessibility To improve the accessibility of the ‘Business Value Score’ data of the ‘Calculate costs’ function.
What is the current accessibility of the ‘Business Value Score’ data of the ‘Calculate costs’ function? What is the deviation of the current accessibility from the desired one?
Location of Data ITSM
F3 - Review and rank the case - SMILE review forum
RFC v2 Accessibility To improve the accessibility of the ‘RFC v2’ data of the ‘Review and rank the case’ function.
What is the current accessibility of the ‘RFCv2’ data of the ‘Review and rank the case’ function? What is the deviation of the current accessibility from the desired one?
Location of Data ITSM
Relevancy To improve the relevancy of the ‘RFC v2’ data of the ‘Review and rank the case’ function.
What is the current relevancy of the ‘RFCv2’ data of the ‘Review and rank the case’ function? What is the deviation of the current relevancy from the desired one?
Is change related Yes
Value-added To increase the value-added of the ‘RFC v2’ data of the ‘Review and rank the case’ function.
What is the current value-added of the ‘RFCv2’ data of the ‘Review and rank the case’ function? What is the deviation of the current value-added from the desired one?
Descriptive (Yes/No)
Yes
Completeness To improve the completeness of the ‘RFC v2’ data of the ‘Review and rank the case’ function.
What is the current completeness of the ‘RFCv2’ data of the ‘Review and rank the case’ function? What is the deviation of the
Percentage of populated required fields
> 90%
455
current completeness from the desired one?
Amount of Data To improve the amount of data of the ‘RFC v2’ data of the ‘Review and rank the case’ function.
What is the current amount of data of the ‘RFCv2’ data of the ‘Review and rank the case’ function? What is the deviation of the current amount of data from the desired one?
Enough data exists to describe risks and opportunities
Yes
Business Value Score
Accessibility To improve the accessibility of the ‘Business Value Score’ data of the ‘Review and rank the case’ function.
What is the current accessibility of the ‘Business Value Score’ data of the ‘Review and rank the case’ function? What is the deviation of the current accessibility from the desired one?
Location of Data ITSM
Relevancy To improve the relevancy of the ‘Business Value Score’ data of the ‘Review and rank the case’ function.
What is the current relevancy of the ‘Business Value Score’ data of the ‘Review and rank the case’ function? What is the deviation of the current relevancy from the desired one?
Business Score present
Yes
Value-added To increase the value-added of the ‘Business Value Score’ data of the ‘Review and rank the case’ function.
What is the current value-added of the ‘Business Value Score’ data of the ‘Review and rank the case’ function? What is the deviation of the current value-added from the desired one?
Descriptive (Yes/No)
Yes
Completeness To improve the completeness of the ‘Business Value Score’ data of the ‘Review and rank the case’ function.
What is the current completeness of the ‘Business Value Score’ data of the ‘Review and rank the case’ function? What is the deviation of the current completeness from the desired one?
Business Score present
Yes
Amount of Data To improve the amount of data of the ‘Business Value Score’ data of the ‘Review and rank the case’ function.
What is the current amount of data of the ‘Business Value Score’ data of the ‘Review and rank the case’ function? What is the deviation of the current amount
Business Score present
Yes
456
of data from the desired one?
Priority List Accessibility To improve the accessibility of the ‘Priority List’ data of the ‘Review and rank the case’ function.
What is the current accessibility of the ‘Priority List’ data of the ‘Review and rank the case’ function? What is the deviation of the current accessibility from the desired one?
Location of Data SMILE forum repository
Relevancy To improve the relevancy of the ‘Priority List’ data of the ‘Review and rank the case’ function.
What is the current relevancy of the ‘Priority List’ data of the ‘Review and rank the case’ function? What is the deviation of the current relevancy from the desired one?
Rankings present Yes
Value-added To increase the value-added of the ‘Priority List’ data of the ‘Review and rank the case’ function.
What is the current value-added of the ‘Priority List’ data of the ‘Review and rank the case’ function? What is the deviation of the current value-added from the desired one?
Rankings distributed
Yes
Completeness To improve the completeness of the ‘Priority List’ data of the ‘Review and rank the case’ function.
What is the current completeness of the ‘Priority List’ data of the ‘Review and rank the case’ function? What is the deviation of the current completeness from the desired one?
All RFC’s ranked Yes
Amount of Data To improve the amount of data of the ‘Priority List’ data of the ‘Review and rank the case’ function.
What is the current amount of data of the ‘Priority List’ data of the ‘Review and rank the case’ function? What is the deviation of the current amount of data from the desired one?
Enough data exists to describe rankings
Yes
F4 - Enter SMILE ranking into ITSM
Priority List Accuracy To improve the accuracy of the ‘Priority List’ data of the ‘Enter SMILE ranking into ITSM’ function.
What is the current accuracy of the ‘Priority List’ data of the ‘Enter SMILE ranking into ITSM’ function? What is the deviation of the current accuracy from the
Subjective evaluation
n/a
457
desired one?
Objectivity To improve the objectivity of the ‘Priority List’ data of the ‘Enter SMILE ranking into ITSM’ function.
What is the current objectivity of the ‘Priority List’ data of the ‘Enter SMILE ranking into ITSM’ function? What is the deviation of the current objectivity from the desired one?
Collection Method
SMILE forum
Believability To improve the believability of the ‘Priority List’ data of the ‘Enter SMILE ranking into ITSM’ function.
What is the current believability of the ‘Priority List’ data of the ‘Enter SMILE ranking into ITSM’ function? What is the deviation of the current believability from the desired one?
Source of Data SMILE minutes
Reputation To improve the reputation of the ‘Priority List’ data of the ‘Enter SMILE ranking into ITSM’ function.
What is the current reputation of the ‘Priority List’ data of the ‘Enter SMILE ranking into ITSM’ function? What is the deviation of the current reputation from the desired one?
Source of Data SMILE minutes
Accessibility To improve the accessibility of the ‘Priority List’ data of the ‘Enter SMILE ranking into ITSM’ function.
What is the current accessibility of the ‘Priority List’ data of the ‘Enter SMILE ranking into ITSM’ function? What is the deviation of the current accessibility from the desired one?
Location of Data SMILE forum repository
Relevancy To improve the relevancy of the ‘Priority List’ data of the ‘Enter SMILE ranking into ITSM’ function.
What is the current relevancy of the ‘Priority List’ data of the ‘Enter SMILE ranking into ITSM’ function? What is the deviation of the current relevancy from the desired one?
Rankings present Yes
Value-added To increase the value-added of the ‘Priority List’ data of the ‘Enter SMILE ranking into ITSM’
What is the current value-added of the ‘Priority List’ data of the ‘Enter SMILE ranking into ITSM’ function? What is the deviation
Rankings distributed
Yes
458
function. of the current value-added from the desired one?
Completeness To improve the completeness of the ‘Priority List’ data of the ‘Enter SMILE ranking into ITSM’ function.
What is the current completeness of the ‘Priority List’ data of the ‘Enter SMILE ranking into ITSM’ function? What is the deviation of the current completeness from the desired one?
All RFC’s ranked Yes
Amount of Data To improve the amount of data of the ‘Priority List’ data of the ‘Enter SMILE ranking into ITSM’ function.
What is the current amount of data of the ‘Priority List’ data of the ‘Enter SMILE ranking into ITSM’ function? What is the deviation of the current amount of data from the desired one?
Enough data exists to describe rankings
Yes
F5 - Communicate to staff and clients
Priority List Accessibility To improve the accessibility of the ‘Priority List’ data of the ‘Communicate to staff and clients’ function.
What is the current accessibility of the ‘Priority List’ data of the ‘Communicate to staff and clients’ function? What is the deviation of the current accessibility from the desired one?
Location of Data SMILE forum repository
Relevancy To improve the relevancy of the ‘Priority List’ data of the ‘Communicate to staff and clients’ function.
What is the current relevancy of the ‘Priority List’ data of the ‘Communicate to staff and clients’ function? What is the deviation of the current relevancy from the desired one?
Rankings present Yes
Value-added To increase the value-added of the ‘Priority List’ data of the ‘Communicate to staff and clients’ function.
What is the current value-added of the ‘Priority List’ data of the ‘Communicate to staff and clients’ function? What is the deviation of the current value-added from the desired one?
Rankings distributed
Yes
Completeness To improve the completeness of the ‘Priority List’ data of the ‘Communicate to staff and clients’ function.
What is the current completeness of the ‘Priority List’ data of the ‘Communicate to staff and clients’ function? What is the deviation of the current
All RFC’s ranked Yes
459
completeness from the desired one?
Amount of Data To improve the amount of data of the ‘Priority List’ data of the ‘Communicate to staff and clients’ function.
What is the current amount of data of the ‘Priority List’ data of the ‘Communicate to staff and clients’ function? What is the deviation of the current amount of data from the desired one?
Enough data exists to describe rankings
Yes
F6 - Develop the change
RFC v2 Accuracy To improve the accuracy of the ‘RFC v2’ data of the ‘Develop the change’ function.
What is the current accuracy of the ‘RFCv2’ data of the ‘Develop the change’ function? What is the deviation of the current accuracy from the desired one?
Source of data n/a
Relevancy To improve the relevancy of the ‘RFC v2’ data of the ‘Develop the change’ function.
What is the current relevancy of the ‘RFCv2’ data of the ‘Develop the change’ function? What is the deviation of the current relevancy from the desired one?
Describes required change
Yes
Value-added To increase the value-added of the ‘RFC v2’ data of the ‘Develop the change’ function.
What is the current value-added of the ‘RFCv2’ data of the ‘Develop the change’ function? What is the deviation of the current value-added from the desired one?
Descriptive (Yes/No)
Yes
Timeliness To improve the timeliness of the ‘RFC v2’ data of the ‘Develop the change’ function.
What is the current timeliness of the ‘RFCv2’ data of the ‘Develop the change’ function? What is the deviation of the current timeliness from the desired one?
Age of Data < 2months
Completeness To improve the completeness of the ‘RFC v2’ data of the ‘Develop the change’ function.
What is the current completeness of the ‘RFCv2’ data of the ‘Develop the change’ function? What is the deviation of the current completeness from the desired one?
Percentage of fields completed
> 90%
Amount of Data To improve the amount of data of the ‘RFC v2’ data of
What is the current amount of data of the ‘RFCv2’ data of the
Enough data to describe
Yes
460
the ‘Develop the change’ function.
‘Develop the change’ function? What is the deviation of the current amount of data from the desired one?
required change
Accessibility To improve the accessibility of the ‘RFC v2’ data of the ‘Develop the change’ function.
What is the current accessibility of the ‘RFCv2’ data of the ‘Develop the change’ function? What is the deviation of the current accessibility from the desired one?
Location of Data ITSM
Change Accuracy To improve the accuracy of the ‘Change’ data of the ‘Develop the change’ function.
What is the current accuracy of the ‘Change’ data of the ‘Develop the change’ function? What is the deviation of the current accuracy from the desired one?
Subjective evaluation
n/a
Objectivity To improve the objectivity of the ‘Change’ data of the ‘Develop the change’ function.
What is the current objectivity of the ‘Change’ data of the ‘Develop the change’ function? What is the deviation of the current objectivity from the desired one?
Source of Data SME
Believability To improve the believability of the ‘Change’ data of the ‘Develop the change’ function.
What is the current believability of the ‘Change’ data of the ‘Develop the change’ function? What is the deviation of the current believability from the desired one?
Source of Data SME
Reputation To improve the reputation of the ‘Change’ data of the ‘Develop the change’ function.
What is the current reputation of the ‘Change’ data of the ‘Develop the change’ function? What is the deviation of the current reputation from the desired one?
Source of Data SME
Relevancy To improve the relevancy of the ‘Change’ data of the ‘Develop the change’ function.
What is the current relevancy of the ‘Change’ data of the ‘Develop the change’ function? What is the deviation of the current relevancy from the desired one?
Scope matches RFC
Yes
Value-added To increase the value- What is the current value-added Descriptive Yes
461
added of the ‘Change’ data of the ‘Develop the change’ function.
of the ‘Change’ data of the ‘Develop the change’ function? What is the deviation of the current value-added from the desired one?
(Yes/No)
Timeliness To improve the timeliness of the ‘Change’ data of the ‘Develop the change’ function.
What is the current timeliness of the ‘Change’ data of the ‘Develop the change’ function? What is the deviation of the current timeliness from the desired one?
Age of Data < 2 months
Completeness To improve the completeness of the ‘Change’ data of the ‘Develop the change’ function.
What is the current completeness of the ‘Change’ data of the ‘Develop the change’ function? What is the deviation of the current completeness from the desired one?
Percentage of fields completed
< 90%
Amount of Data To improve the amount of data of the ‘Change’ data of the ‘Develop the change’ function.
What is the current amount of data of the ‘Change’ data of the ‘Develop the change’ function? What is the deviation of the current amount of data from the desired one?
Enough data to describe required change
Yes
Accessibility To improve the accessibility of the ‘Change’ data of the ‘Develop the change’ function.
What is the current accessibility of the ‘Change’ data of the ‘Develop the change’ function? What is the deviation of the current accessibility from the desired one?
Location of Data ITSM
F7 - Conduct UAT
Change Accuracy To improve the accuracy of the ‘Change’ data of the ‘Conduct UAT’ function.
What is the current accuracy of the ‘Change’ data of the ‘Conduct UAT’ function? What is the deviation of the current accuracy from the desired one?
Subjective evaluation
n/a
Objectivity To improve the objectivity of the ‘Change’ data of the ‘Conduct UAT’ function.
What is the current objectivity of the ‘Change’ data of the ‘Conduct UAT’ function? What is the deviation of the current objectivity from the desired one?
Source of Data SME
462
Believability To improve the believability of the ‘Change’ data of the ‘Conduct UAT’ function.
What is the current believability of the ‘Change’ data of the ‘Conduct UAT’ function? What is the deviation of the current believability from the desired one?
Source of Data SME
Reputation To improve the reputation of the ‘Change’ data of the ‘Conduct UAT’ function.
What is the current reputation of the ‘Change’ data of the ‘Conduct UAT’ function? What is the deviation of the current reputation from the desired one?
Source of Data SME
Accessibility To improve the accessibility of the ‘Change’ data of the ‘Conduct UAT’ function.
What is the current accessibility of the ‘Change’ data of the ‘Conduct UAT’ function? What is the deviation of the current accessibility from the desired one?
Location of Data ITSM
Relevancy To improve the relevancy of the ‘Change’ data of the ‘Conduct UAT’ function.
What is the current relevancy of the ‘Change’ data of the ‘Conduct UAT’ function? What is the deviation of the current relevancy from the desired one?
Scope matches RFC
Yes
Value-added To increase the value-added of the ‘Change’ data of the ‘Conduct UAT’ function.
What is the current value-added of the ‘Change’ data of the ‘Conduct UAT’ function? What is the deviation of the current value-added from the desired one?
Descriptive (Yes/No)
Yes
Completeness To improve the completeness of the ‘Change’ data of the ‘Conduct UAT’ function.
What is the current completeness of the ‘Change’ data of the ‘Conduct UAT’ function? What is the deviation of the current completeness from the desired one?
Percentage of fields completed
> 90%
Amount of Data To improve the amount of data of the ‘Change’ data of the ‘Conduct UAT’ function.
What is the current amount of data of the ‘Change’ data of the ‘Conduct UAT’ function? What is the deviation of the current
Enough data to describe required change
Yes
463
amount of data from the desired one?
Signed off change
Accuracy To improve the accuracy of the ‘Signed off change’ data of the ‘Conduct UAT’ function.
What is the current accuracy of the ‘Signed off Change’ data of the ‘Conduct UAT’ function? What is the deviation of the current accuracy from the desired one?
Subjective evaluation
n/a
Objectivity To improve the objectivity of the ‘Signed off change’ data of the ‘Conduct UAT’ function.
What is the current objectivity of the ‘Signed off Change’ data of the ‘Conduct UAT’ function? What is the deviation of the current objectivity from the desired one?
Source of Data SME
Believability To improve the believability of the ‘Signed off change’ data of the ‘Conduct UAT’ function.
What is the current believability of the ‘Signed off Change’ data of the ‘Conduct UAT’ function? What is the deviation of the current believability from the desired one?
Source of Data SME
Reputation To improve the reputation of the ‘Signed off change’ data of the ‘Conduct UAT’ function.
What is the current reputation of the ‘Signed off Change’ data of the ‘Conduct UAT’ function? What is the deviation of the current reputation from the desired one?
Source of Data SME
Accessibility To improve the accessibility of the ‘Signed off change’ data of the ‘Conduct UAT’ function.
What is the current accessibility of the ‘Signed off Change’ data of the ‘Conduct UAT’ function? What is the deviation of the current accessibility from the desired one?
Location of Data ITSM
Completeness To improve the completeness of the ‘Signed off change’ data of the ‘Conduct UAT’ function.
What is the current completeness of the ‘Signed off Change’ data of the ‘Conduct UAT’ function? What is the deviation of the current completeness from the
% of required signatures
100%
464
desired one?
F8 - Release Signed off change
Accessibility To improve the accessibility of the ‘Signed off change’ data of the ‘Release’ function.
What is the current accessibility of the ‘Signed off Change’ data of the ‘Release’ function? What is the deviation of the current accessibility from the desired one?
Location of Data ITSM
Completeness To improve the completeness of the ‘Signed off change’ data of the ‘Release’ function.
What is the current completeness of the ‘Signed off Change’ data of the ‘Release’ function? What is the deviation of the current completeness from the desired one?
% of required signatures
100%
F9 - Conduct customer satisfaction survey
Survey Result Accuracy To improve the accuracy of the ‘Survey Result’ data of the ‘Conduct customer satisfaction survey’ function.
What is the current accuracy of the ‘Survey Result’ data of the ‘Conduct customer satisfaction survey’ function? What is the deviation of the current accuracy from the desired one?
Subjective evaluation
n/a
Objectivity To improve the objectivity of the ‘Survey Result’ data of the ‘Conduct customer satisfaction survey’ function.
What is the current objectivity of the ‘Survey Result’ data of the ‘Conduct customer satisfaction survey’ function? What is the deviation of the current objectivity from the desired one?
Participant End user
Believability To improve the believability of the ‘Survey Result’ data of the ‘Conduct customer satisfaction survey’ function.
What is the current believability of the ‘Survey Result’ data of the ‘Conduct customer satisfaction survey’ function? What is the deviation of the current believability from the desired one?
Participant End User
Reputation To improve the reputation of the ‘Survey Result’ data of the ‘Conduct customer satisfaction survey’
What is the current reputation of the ‘Survey Result’ data of the ‘Conduct customer satisfaction survey’ function? What is the
Participant End User
465
function. deviation of the current reputation from the desired one?
Accessibility To improve the accessibility of the ‘Survey Result’ data of the ‘Conduct customer satisfaction survey’ function.
What is the current accessibility of the ‘Survey Result’ data of the ‘Conduct customer satisfaction survey’ function? What is the deviation of the current accessibility from the desired one?
Location of Data ITSM
Relevancy To improve the relevancy of the ‘Survey Result’ data of the ‘Conduct customer satisfaction survey’ function.
What is the current relevancy of the ‘Survey Result’ data of the ‘Conduct customer satisfaction survey’ function? What is the deviation of the current relevancy from the desired one?
Related to change
Yes
Value-added To increase the value-added of the ‘Survey Result’ data of the ‘Conduct customer satisfaction survey’ function.
What is the current value-added of the ‘Survey Result’ data of the ‘Conduct customer satisfaction survey’ function? What is the deviation of the current value-added from the desired one?
Answers descriptive
Yes
Completeness To improve the completeness of the ‘Survey Result’ data of the ‘Conduct customer satisfaction survey’ function.
What is the current completeness of the ‘Survey Result’ data of the ‘Conduct customer satisfaction survey’ function? What is the deviation of the current completeness from the desired one?
% questions answered
> 90%
466
Appendix D.8 Human Resource Measurement Model
Functions Resource Quality Characteristics
Soft Goals Question Metric Threshold Value
F1 - Enter request details into ITSM
Operations Relationship Manager (ORM)
Experience To improve the experience of the ORM performing the ‘Enter request details into ITSM’ function.
What is the current experience of the ORM? What is the deviation of the current experience to the desired one?
Change Management experience
>= 3 years
Time Management Efficiency
To improve the time management of the ORM performing the ‘Enter request details into ITSM’ function.
What is the current time management efficiency of the ORM? What is the deviation of the current time management efficiency to the desired one?
Time to enter request
< 4 hours
F2 - Calculate Costs
Change Manager
Domain Knowledge
To improve the domain knowledge of the Change Manager performing the ‘Calculate Costs’ function.
What is the current domain knowledge of the Change Manager? What is the deviation of the current domain knowledge from the desired one?
Estimation techniques knowledge level (none, basic, intermediate, expert)
>= intermediate
Experience To improve the experience of the Change Manager performing the ‘Calculate Costs’ function.
What is the current experience of the Change Manager? What is the deviation of the current experience to the desired one?
Change Management experience
>= 5 years
Time Management Efficiency
To improve the time management of the Change Manager performing the ‘Calculate Costs’ function.
What is the current time management efficiency of the Change Manager? What is the deviation of the current time management efficiency to the desired one?
Time to calculate costs
> 3 days
F3 - Review and rank the case - SMILE review form
SMILE review committee
Domain Knowledge
To improve the domain knowledge of the SMILE review committee performing the ‘Review
What is the current domain knowledge of the SMILE review committee? What is the deviation of the current domain knowledge
Project pipeline knowledge level (none, basic, intermediate,
>= intermediate
467
and rank the case’ function.
from the desired one? expert)
Experience To improve the experience of the SMILE review committee performing the ‘Review and rank the case’ function.
What is the current experience of the SMILE review committee? What is the deviation of the current experience to the desired one?
Change Management experience
> 3 years (on average)
Time Management Efficiency
To improve the time management of the SMILE review committee performing the ‘Review and rank the case’ function.
What is the current time management efficiency of the SMILE review committee? What is the deviation of the current time management efficiency to the desired one?
Review time < 7 days
Communication Skill
To improve the communication skill of the SMILE review committee performing the ‘Review and rank the case’ function.
What is the current communication skill of the SMILE review committee? What is the deviation of the current communication skill to the desired one?
Negotiation skill level (poor, average, good)
= good
F4 - Enter SMILE ranking into ITSM
Operations Relationship Manager (ORM)
Experience To improve the experience of the ORM performing the ‘Enter SMILE ranking into ITSM’ function.
What is the current experience of the ORM? What is the deviation of the current experience to the desired one?
ITSM system experience
> 2 years
F5 - Communicate to staff and clients
Operations Relationship Manager (ORM)
Experience To improve the experience of the ORM performing the ‘Communicate to staff and clients’ function.
What is the current experience of the ORM? What is the deviation of the current experience to the desired one?
Stakeholder management experience
> 3 years
Time Management Efficiency
To improve the time management efficiency of the ORM performing the ‘Communicate to staff and clients’ function.
What is the current time management efficiency of the ORM? What is the deviation of the current time management efficiency to the desired one?
Turnaround time
< 1 day
468
Communication Skill
To improve the communication skill of the ORM performing the ‘Communicate to staff and clients’ function.
What is the current communication skill of the ORM? What is the deviation of the current communication skill to the desired one?
Written skills (grammar, spelling, technical etc.) (poor, average, good)
= good
Verbal skills (speaking clearly and effectively) (poor, average, good)
= good
F6 - Develop the change
IT Team Domain Knowledge
To improve the domain knowledge of the IT Team performing the ‘Develop the Change’ function.
What is the current domain knowledge of the IT Team? What is the deviation of the current domain knowledge from the desired one?
Software Development knowledge level (none, basic, intermediate, expert)
>= intermediate
Qualification To improve the qualification level of the IT Team performing the ‘Develop the change’ function.
What is the current qualification level of the IT Team? What is the deviation of the current qualification level from the desired one?
IT based qualification
>= degree
Experience To improve the experience of the IT Team performing the ‘Develop the change’ function.
What is the current experience of the IT Team? What is the deviation of the current experience from the desired one?
Software development experience
> 4 years
Financial services experience
> 2 years
Time Management Efficiency
To improve the time management efficiency of the IT Team performing the ‘Develop the change’ function.
What is the current time management efficiency of the IT Team? What is the deviation of the current time management efficiency from the desired one?
Days per function point developed
< 4 days
469
Communication Skill
To improve the communication skill of the IT Team performing the ‘Develop the change’ function.
What is the current communication skill of the IT Team? What is the deviation of the current communication skill from the desired one?
Elicitation skills ( ability to elicit requirements) (poor, average, good)
= good
F7 - Conduct UAT
Business Team
Domain Knowledge
To improve the domain knowledge of the Business Team performing the ‘Conduct UAT’ function.
What is the current domain knowledge of the Business Team? What is the deviation of the current domain knowledge from the desired one?
Financial services knowledge level (none, basic, intermediate, expert)
>= intermediate
Experience To improve the experience of the Business Team performing the ‘Conduct UAT’ function.
What is the current experience of the Business Team? What is the deviation of the current experience from the desired one?
Testing experience
> 2 years
Time Management Efficiency
To improve the time management efficiency of the Business Team performing the ‘Conduct UAT’ function.
What is the current time management efficiency of the Business Team? What is the deviation of the current time management efficiency from the desired one?
Days per function point to test
< 2 days
Communication Skill
To improve the communication skill of the Business Team performing the ‘Conduct UAT’ function.
What is the current communication skill of the Business Team? What is the deviation of the current communication skill from the desired one?
Written skills (grammar, spelling, technical etc.) (poor, average, good)
= good
F8 - Release Release Manager
Time Management Efficiency
To improve the time management efficiency of the Release Manager performing the ‘Release’ function.
What is the current time management efficiency of the Release Manager? What is the deviation of the current time management efficiency from the desired one?
Release time < 4 days
Communication Skill
To improve the communication skill of the Release Manager performing the ‘Release’
What is the current communication skill of the Release Manager? What is the deviation of the current communication skill from the
Written skills (grammar, spelling, technical etc.)
>= average
470
function. desired one? (poor, average, good)
471
Appendix D.9 Non-Human Resource Measurement Model
Organisation B – Non-Human Resource Measurement Model
Functions System Quality Characteristics
Soft Goals Question Metric Threshold Value
F1 - Enter request details into ITSM
ITSM Accuracy To improve the accuracy of the ITSM system performing the ‘Enter request details into ITSM’ function.
What is the current accuracy of the ‘Enter request details into ITSM’ function? What is the deviation of the current accuracy from the desired one?
Subjective evaluation
n/a
Reliability To improve the reliability of the ITSM system performing the ‘Enter request details into ITSM’ function.
What is the current reliability of the ‘Enter request details into ITSM’ function? What is the deviation of the current reliability from the desired one?
Percentage uptime (%)
> 99%
Understandability To improve the understandability of the ITSM system performing the ‘Enter request details into ITSM’ function.
What is the current understandability of the ‘Enter request details into ITSM’ function? What is the deviation of the current understandability from the desired one?
Is a ‘User Guide’ available?
Yes
Is ‘Help Documentation’ available?
Yes
F2 - Calculate Costs
ITSM Accuracy To improve the accuracy of the ITSM system performing the ‘Calculate costs’ function.
What is the current accuracy of the ‘Calculate Costs’ function? What is the deviation of the current accuracy from the desired one?
Subjective evaluation
n/a
Time behaviour efficiency
To increase the time behaviour efficiency of the ITSM system performing the ‘Calculate costs’ function.
What is the current time behaviour efficiency of the ‘Calculate Costs’ function? What is the deviation of the current time behaviour efficiency from the desired one?
Turnaround Time
< 2 days
472
Waiting Time < 1 day
Effectiveness To improve the effectiveness of the ITSM system performing the ‘Calculate costs’ function.
What is the current effectiveness of the ‘Calculate Costs’ function? What is the deviation of the current effectiveness from the desired one?
Error Frequency
< 4 days
F3 - Review and rank the case - SMILE review form
ITSM Reliability To improve the reliability of the ITSM system performing the ‘Review and rank the case’ function.
What is the current reliability of the ‘Review and rank the case’ function? What is the deviation of the current reliability from the desired one?
Percentage uptime (%)
> 99%
Effectiveness To improve the effectiveness of the ITSM system performing the ‘Review and rank the case’ function.
What is the current effectiveness of the ‘Review and rank the case’ function? What is the deviation of the current effectiveness from the desired one?
Error Frequency
< 4%
Satisfaction To increase the satisfaction of the ITSM system performing the ‘Review and rank the case’ function.
What is the current satisfaction of the ‘Review and rank the case’ function? What is the deviation of the current satisfaction from the desired one?
Satisfaction Scale (low, medium, high)
>= medium
F4 - Enter SMILE ranking into ITSM
ITSM Accuracy To improve the accuracy of the ITSM system performing the ‘Enter SMILE ranking into ITSM’ function.
What is the current accuracy of the ‘Enter SMILE ranking into ITSM’ function? What is the deviation of the current accuracy from the desired one?
Subjective evaluation
n/a
Reliability To improve the reliability of the ITSM system performing the ‘Enter SMILE ranking into ITSM’ function.
What is the current reliability of the ‘Enter SMILE ranking into ITSM’ function? What is the deviation of the current reliability from the desired one?
Percentage uptime (%)
> 99%
Effectiveness To improve the effectiveness of the ITSM system performing the ‘Enter SMILE ranking into ITSM’ function.
What is the current effectiveness of the ‘Enter SMILE ranking into ITSM’ function? What is the deviation of the current effectiveness from the desired one?
Error Frequency
< 1%
473
Appendix E
Action Research Organisation C
474
Appendix E.1 Functions Softgoal Model
Organisation C – Functions Softgoal Model
Functions Quality Characteristics Soft Goals
F1 - Classify FSR Suitability To improve the suitability of the ‘Classify FSR’ function.
Accuracy To improve the accuracy of the ‘Classify FSR’ function.
Time behaviour efficiency To improve the time behaviour efficiency of the ‘Classify FSR’ function.
F2 - Prioritise FSR Suitability To improve the suitability of the ‘Prioritise FSR’ function.
Time behaviour efficiency To improve the time behaviour efficiency of the ‘Prioritise FSR’ function.
Effectiveness To improve the effectiveness of the ‘Prioritise FSR’ function.
F3 - Categorise FSR Suitability To improve the suitability of the ‘Categorise FSR’ function.
Time behaviour efficiency To improve the time behaviour efficiency of the ‘Categorise FSR’ function.
Effectiveness To improve the effectiveness of the ‘Categorise FSR’ function.
F4 - Assign FSR Accuracy To improve the accuracy of the ‘Assign FSR’ function.
Reliability To improve the reliability of the ‘Assign FSR’ function.
Time behaviour efficiency To improve the time behaviour efficiency of the ‘Assign FSR’ function.
475
Appendix E.2 Input & Output Softgoal Model
Organisation C – Input & Output Softgoal Model
Function Input/Output Data Quality Characteristics Soft Goals
F1 - Classify FSR FSR Accuracy To improve the accuracy of the ‘FSR’ data of the ‘Classify FSR’ function.
Objectivity To improve the objectivity of the ‘FSR’ data of the ‘Classify FSR’ function.
Believability To improve the believability of the ‘FSR’ data of the ‘Classify FSR’ function.
Reputation To improve the reputation of the ‘FSR’ data of the ‘Classify FSR’ function.
Relevancy To improve the relevancy of the ‘FSR’ data of the ‘Classify FSR’ function.
Value-added To increase the added value of the ‘FSR’ data of the ‘Classify FSR’ function.
Timeliness To improve the timeliness of the ‘FSR’ data of the ‘Classify FSR’ function.
Completeness To improve the completeness of the ‘‘FSR’ data of the ‘Classify FSR’ function.
Amount of Data To improve the amount of data of the ‘FSR’ data of the ‘Classify FSR’ function.
Understandability To improve the understandability of the ‘FSR’ data of the ‘Classify FSR’ function.
F2 - Prioritise FSR FSR Accuracy To improve the accuracy of the ‘FSR’ data of the ‘Prioritise FSR’ function.
Objectivity To improve the objectivity of the ‘FSR’ data of the ‘Prioritise FSR’ function.
Believability To improve the believability of the ‘FSR’ data of the ‘Prioritise FSR’ function.
Reputation To improve the reputation of the ‘FSR’ data of the ‘Prioritise FSR’ function.
Relevancy To improve the relevancy of the ‘FSR’ data of the ‘Prioritise FSR’ function.
476
Value-added To increase the added value of the ‘FSR’ data of the ‘Prioritise FSR’ function.
Timeliness To improve the timeliness of the ‘FSR’ data of the ‘Prioritise FSR’ function.
Completeness To improve the completeness of the ‘FSR’ data of the ‘Prioritise FSR’ function.
Amount of Data To improve the amount of data of the ‘FSR’ data of the ‘Prioritise FSR’ function.
Understandability To improve the understandability of the ‘FSR’ data of the ‘Prioritise FSR’ function.
F3 - Categorise FSR FSR Accuracy To improve the accuracy of the ‘FSR’ data of the ‘Categorise FSR’ function.
Objectivity To improve the objectivity of the ‘FSR’ data of the ‘Categorise FSR’ function.
Believability To improve the believability of the ‘FSR’ data of the ‘Categorise FSR’ function.
Reputation To improve the reputation of the ‘FSR’ data of the ‘Categorise FSR’ function.
Relevancy To improve the relevancy of the ‘FSR’ data of the ‘Categorise FSR’ function.
Value-added To increase the added value of the ‘FSR’ data of the ‘Categorise FSR’ function.
Timeliness To improve the timeliness of the ‘FSR’ data of the ‘Categorise FSR’ function.
Completeness To improve the completeness of the ‘FSR’ data of the ‘Categorise FSR’ function.
Amount of Data To improve the amount of data of the ‘FSR’ data of the ‘Categorise FSR’ function.
Understandability To improve the understandability of the ‘FSR’ data of the ‘Categorise FSR’ function.
F4 - Assign FSR FSR Accuracy To improve the accuracy of the ‘FSR’ data of the ‘Assign FSR’ function.
Objectivity To improve the objectivity of the ‘FSR’ data of the ‘Assign FSR’ function.
Believability To improve the believability of the ‘FSR’ data of the ‘Assign FSR’
477
function.
Reputation To improve the reputation of the ‘FSR’ data of the ‘Assign FSR’ function.
Relevancy To improve the relevancy of the ‘FSR’ data of the ‘Assign FSR’ function.
Value-added To increase the added value of the ‘FSR’ data of the ‘Assign FSR’ function.
Completeness To improve the completeness of the ‘FSR’ data of the ‘Assign FSR’ function.
Amount of Data To improve the amount of data of the ‘FSR’ data of the ‘Assign FSR’ function.
Understandability To improve the understandability of the ‘FSR’ data of the ‘Assign FSR’ function.
Email Receipt Accuracy To improve the accuracy of the ‘Email Receipt’ data of the ‘Assign FSR’ function.
Objectivity To improve the objectivity of the ‘Email Receipt’ data of the ‘Assign FSR’ function.
Believability To improve the believability of the ‘Email Receipt’ data of the ‘Assign FSR’ function.
Reputation To improve the reputation of the ‘Email Receipt’ data of the ‘Assign FSR’ function.
Relevancy To improve the relevancy of the ‘Email Receipt’ data of the ‘Assign FSR’ function.
Value-added To increase the added value of the ‘Email Receipt’ data of the ‘Assign FSR’ function.
Completeness To improve the completeness of the ‘Email Receipt’ data of the ‘Assign FSR’ function.
Amount of Data To improve the amount of data of the ‘Email Receipt’ data of the ‘Assign FSR’ function.
Understandability To improve the understandability of the ‘Email Receipt’ data of the ‘Assign FSR’ function.
478
Appendix E.3 Human Resource Softgoal Model
Organisation C – Human Resource Softgoal Model
Functions Resource Quality Characteristics
Soft Goals
F1 - Classify FSR Help Desk Officer
Domain Knowledge
To improve the domain knowledge of the Help Desk Officer performing the ‘Classify FSR’ function.
Time Management
To improve the time management skill of the Help Desk Officer performing the ‘Classify FSR’ function.
Experience To increase the experience of the Help Desk Officer performing the ‘Classify FSR’ function.
F2 - Prioritise FSR Help Desk Officer
Domain Knowledge
To improve the domain knowledge of the Help Desk Officer performing the ‘Prioritise FSR’ function.
Time Management
To improve the time management skill of the Help Desk Officer performing the ‘Prioritise FSR’ function.
Experience To increase the experience of the Help Desk Officer performing the ‘Prioritise FSR’ function.
F3 - Categorise FSR Help Desk Officer
Domain Knowledge
To improve the domain knowledge of the Help Desk Officer performing the ‘Categorise FSR’ function.
Experience To increase the experience of the Help Desk Officer performing the ‘Categorise FSR’ function.
Time Management
To improve the time management skill of the Help Desk Officer performing the ‘Categorise FSR’ function.
F4 - Assign FSR Help Desk Officer
Domain Knowledge
To improve the domain knowledge of the Help Desk Officer performing the ‘Assign FSR’ function.
Experience To increase the experience of the Help Desk Officer performing the ‘Assign FSR’ function.
Time Management
To improve the time management skill of the Help Desk Officer performing the ‘Assign FSR’ function.
Communication Skill
To improve the communication skill of the Help Desk Officer performing the ‘Assign FSR’ function.
479
Appendix E.4 Non-Human Resource Softgoal Model
Organisation C – Non-Human Resource Softgoal Model
Functions Resource Quality Characteristics
Soft Goals
F1 - Classify FSR Help Desk System
Suitability To improve the suitability of the Help Desk System performing the ‘Classify FSR’ function.
Accuracy To improve the accuracy of the Help Desk System performing the ‘Classify FSR’ function.
Time behaviour efficiency
To improve the time behaviour efficiency of the Help Desk System performing the ‘Classify FSR’ function.
F2 - Prioritise FSR Help Desk System
Suitability To improve the suitability of the Help Desk System performing the ‘Prioritise FSR’ function.
Time behaviour efficiency
To improve the time behaviour efficiency of the Help Desk System performing the ‘Prioritise FSR’ function.
Effectiveness To improve the effectiveness of the Help Desk System performing the ‘Prioritise FSR’ function.
F3 - Categorise FSR
Help Desk System
Suitability To improve the suitability of the Help Desk System performing the ‘Categorise FSR’ function.
Time behaviour efficiency
To improve the time behaviour efficiency of the Help Desk System performing the ‘Categorise FSR’ function.
Effectiveness To improve the effectiveness of the Help Desk System performing the ‘Categorise FSR’ function.
F4 - Assign FSR Help Desk System
Accuracy To improve the accuracy of the Help Desk System performing the ‘Assign FSR’ function.
Reliability To improve the reliability of the Help Desk System performing the ‘Assign FSR’ function.
Time behaviour efficiency
To improve the time behaviour efficiency of the Help Desk System performing the ‘Assign FSR’ function.
480
Appendix E.5 Softgoal Correlation Model
Organisation C – Softgoal Correlation Model
Functions Input Output Function
Correlated Soft Goal
F4 - Assign FSR FSR F1 To improve the suitability of the ‘Classify FSR’ function.
To improve the accuracy of the ‘Classify FSR’ function.
To improve the time behaviour efficiency of the ‘Classify FSR’ function.
F2 To improve the suitability of the ‘Prioritise FSR’ function.
To improve the time behaviour efficiency of the ‘Prioritise FSR’ function.
To improve the effectiveness of the ‘Prioritise FSR’ function.
F3 To improve the suitability of the ‘Categorise FSR’ function.
To improve the time behaviour efficiency of the ‘Categorise FSR’ function.
To improve the effectiveness of the ‘Categorise FSR’ function.
F3 - Categorise FSR FSR F1 To improve the suitability of the ‘Classify FSR’ function.
To improve the accuracy of the ‘Classify FSR’ function.
To improve the time behaviour efficiency of the ‘Classify FSR’ function.
F2 To improve the suitability of the ‘Prioritise FSR’ function.
To improve the time behaviour efficiency of the ‘Prioritise FSR’ function.
To improve the effectiveness of the ‘Prioritise FSR’ function.
F2 - Prioritise FSR FSR F1 To improve the suitability of the ‘Classify FSR’ function.
To improve the accuracy of the ‘Classify FSR’ function.
To improve the time behaviour efficiency of the ‘Classify FSR’ function.
481
Appendix E.6 Function Measurement Model
Organisation C – Function Measurement Model
Functions Quality Characteristics
Soft Goals Question Metric Threshold Value
F1 - Classify FSR
Suitability To improve the suitability of the ‘Classify FSR’ function.
What is the current suitability of the ‘Classify FSR’ function? What is the deviation of the current suitability from the desired one?
FSR is classified Yes
Accuracy To improve the accuracy of the ‘Classify FSR’ function.
What is the current accuracy of the ‘Classify FSR’ function? What is the deviation of the current accuracy from the desired one?
Subjective evaluation n/a
Time behaviour efficiency
To improve the time behaviour efficiency of the ‘Classify FSR’ function.
What is the current time behaviour efficiency of the ‘Classify FSR’ function? What is the deviation of the current time behaviour efficiency from the desired one?
Turnaround Time < 5 minutes
Waiting Time < 5 minutes
F2 - Prioritise FSR
Suitability To improve the suitability of the ‘Prioritise FSR’ function.
What is the current suitability of the ‘Prioritise FSR’ function? What is the deviation of the current suitability from the desired one?
FSR is prioritised Yes
Time behaviour efficiency
To improve the time behaviour efficiency of the ‘Prioritise FSR’ function.
What is the current time behaviour efficiency of the ‘Prioritise FSR’ function? What is the deviation of the current time behaviour efficiency from the desired one?
Turnaround Time < 5 minutes
Waiting Time < 5 minutes
482
Effectiveness To improve the effectiveness of the ‘Prioritise FSR’ function.
What is the current effectiveness of the ‘Prioritise FSR’ function? What is the deviation of the current effectiveness from the desired one?
Error Frequency < 2%
F3 - Categorise FSR
Suitability To improve the suitability of the ‘Categorise FSR’ function.
What is the current suitability of the ‘Categorise FSR’ function? What is the deviation of the current suitability from the desired one?
FSR is categorised Yes
Time behaviour efficiency
To improve the time behaviour efficiency of the ‘Categorise FSR’ function.
What is the current time behaviour efficiency of the ‘Categorise FSR’ function? What is the deviation of the current time behaviour efficiency from the desired one?
Turnaround Time < 1 minute
Waiting Time < 1 minute
Effectiveness To improve the effectiveness of the ‘Categorise FSR’ function.
What is the current effectiveness of the ‘Categorise FSR’ function? What is the deviation of the current effectiveness from the desired one?
Error Frequency < 2%
F4 - Assign FSR
Accuracy To improve the accuracy of the ‘Assign FSR’ function.
What is the current accuracy of the ‘Assign FSR’ function? What is the deviation of the current accuracy from the desired one?
Subjective evaluation n/a
Reliability To improve the reliability of the ‘Assign FSR’ function.
What is the current reliability of the ‘Assign FSR’ function? What is the deviation of the current reliability from the desired one?
Percentage uptime (%)
> 99.998%
Time behaviour efficiency
To improve the time behaviour efficiency of the ‘Assign FSR’ function.
What is the current time behaviour efficiency of the ‘Assign FSR’ function? What is the deviation of the current time behaviour efficiency from the desired one?
Turnaround Time < 1 minute
483
Appendix E.7 Input & Output Measurement Model
Organisation C – Input & Output Measurement Model
Function Input/Output Data
Quality Characteristics
Soft Goals Question Metric Threshold Value
F1 - Classify FSR FSR Accuracy To improve the accuracy of the ‘FSR’ data of the ‘Classify FSR’ function.
What is the current accuracy of the ‘FSR’ data of the ‘Classify FSR’ function? What is the deviation of the current accuracy from the desired one?
Collection Method (system, email, phone)
<> phone
Objectivity To improve the objectivity of the ‘FSR’ data of the ‘Classify FSR’ function.
What is the current objectivity of the ‘FSR’ data of the ‘Classify FSR’ function? What is the deviation of the current objectivity from the desired one?
Collection Method (system, email, phone)
= system
Believability To improve the believability of the ‘FSR’ data of the ‘Classify FSR’ function.
What is the current believability of the ‘FSR’ data of the ‘Classify FSR’ function? What is the deviation of the current believability from the desired one?
Source of Data (system, basic user, power user)
<> basic user
Reputation To improve the reputation of the ‘FSR’ data of the ‘Classify FSR’ function.
What is the current reputation of the ‘FSR’ data of the ‘Classify FSR’ function? What is the deviation of the current reputation from the desired one?
Source of Data (system, basic user, power user)
<> basic user
Collection Method (system, email, phone)
= system
Relevancy To improve the relevancy of the ‘FSR’ data of the ‘Classify FSR’ function.
What is the current relevancy of the ‘FSR’ data of the ‘Classify FSR’ function? What is the deviation of the current relevancy from the desired one?
Fault Related Yes
484
Value-added To increase the added value of the ‘FSR’ data of the ‘Classify FSR’ function.
What is the current added value of the ‘FSR’ data of the ‘Classify FSR’ function? What is the deviation of the current added value from the desired one?
Descriptive (Yes/No)
Yes
Timeliness To improve the timeliness of the ‘FSR’ data of the ‘Classify FSR’ function.
What is the current timeliness of the ‘FSR’ data of the ‘Classify FSR’ function? What is the deviation of the current timeliness from the desired one?
Age of Data < 2 hours
Completeness To improve the completeness of the ‘‘FSR’ data of the ‘Classify FSR’ function.
What is the current completeness of the ‘FSR’ data of the ‘Classify FSR’ function? What is the deviation of the current completeness from the desired one?
Percentage of populated required fields
> 90%
Amount of Data To improve the amount of data of the ‘FSR’ data of the ‘Classify FSR’ function.
What is the current amount of data of the ‘FSR’ data of the ‘Classify FSR’ function? What is the deviation of the current amount of data from the desired one?
Percentage of populated fields
> 80%
Understandability To improve the understandability of the ‘FSR’ data of the ‘Classify FSR’ function.
What is the current understandability of the ‘FSR’ data of the ‘Classify FSR’ function? What is the deviation of the current understandability from the desired one?
Fault description is well described (Yes/No)
Yes
F2 - Prioritise FSR
FSR Accuracy To improve the accuracy of the ‘FSR’ data of the ‘Prioritise FSR’ function.
What is the current accuracy of the ‘FSR’ data of the ‘Prioritise FSR’ function? What is the deviation of the current accuracy from the desired one?
Collection Method (system, email, phone)
<> phone
Objectivity To improve the objectivity of the ‘FSR’ data of the ‘Prioritise FSR’ function.
What is the current objectivity of the ‘FSR’ data of the ‘Prioritise FSR’ function? What is the deviation of the current objectivity from the desired one?
Collection Method (system, email, phone)
= system
485
Believability To improve the believability of the ‘FSR’ data of the ‘Prioritise FSR’ function.
What is the current believability of the ‘FSR’ data of the ‘Prioritise FSR’ function? What is the deviation of the current believability from the desired one?
Source of Data (system, basic user, power user)
<> basic user
Reputation To improve the reputation of the ‘FSR’ data of the ‘Prioritise FSR’ function.
What is the current reputation of the ‘FSR’ data of the ‘Prioritise FSR’ function? What is the deviation of the current reputation from the desired one?
Source of Data (system, basic user, power user)
<> basic user
Collection Method (system, email, phone)
= system
Relevancy To improve the relevancy of the ‘FSR’ data of the ‘Prioritise FSR’ function.
What is the current relevancy of the ‘FSR’ data of the ‘Prioritise FSR’ function? What is the deviation of the current relevancy from the desired one?
Fault Related Yes
Value-added To increase the added value of the ‘FSR’ data of the ‘Prioritise FSR’ function.
What is the current added value of the ‘FSR’ data of the ‘Prioritise FSR’ function? What is the deviation of the current added value from the desired one?
Descriptive (Yes/No)
Yes
Timeliness To improve the timeliness of the ‘FSR’ data of the ‘Prioritise FSR’ function.
What is the current timeliness of the ‘FSR’ data of the ‘Prioritise FSR’ function? What is the deviation of the current timeliness from the desired one?
Age of Data < 2 hours
Completeness To improve the completeness of the ‘FSR’ data of the ‘Prioritise FSR’ function.
What is the current completeness of the ‘FSR’ data of the ‘Prioritise FSR’ function? What is the deviation of the current completeness from the desired one?
Percentage of populated required fields
> 90%
Amount of Data To improve the amount of data of the ‘FSR’ data of the
What is the current amount of data of the ‘FSR’ data of the ‘Prioritise FSR’ function? What is the deviation
Percentage of populated fields
> 80%
486
‘Prioritise FSR’ function.
of the current amount of data from the desired one?
Understandability To improve the understandability of the ‘FSR’ data of the ‘Prioritise FSR’ function.
What is the current understandability of the ‘FSR’ data of the ‘Prioritise FSR’ function? What is the deviation of the current understandability from the desired one?
Fault description is well described (Yes/No)
Yes
F3 - Categorise FSR
FSR Accuracy To improve the accuracy of the ‘FSR’ data of the ‘Categorise FSR’ function.
What is the current accuracy of the ‘FSR’ data of the ‘Categorise FSR’ function? What is the deviation of the current accuracy from the desired one?
Collection Method (system, email, phone)
<> phone
Objectivity To improve the objectivity of the ‘FSR’ data of the ‘Categorise FSR’ function.
What is the current objectivity of the ‘FSR’ data of the ‘Categorise FSR’ function? What is the deviation of the current objectivity from the desired one?
Collection Method (system, email, phone)
= system
Believability To improve the believability of the ‘FSR’ data of the ‘Categorise FSR’ function.
What is the current believability of the ‘FSR’ data of the ‘Categorise FSR’ function? What is the deviation of the current believability from the desired one?
Source of Data (system, basic user, power user)
<> basic user
Reputation To improve the reputation of the ‘FSR’ data of the ‘Categorise FSR’ function.
What is the current reputation of the ‘FSR’ data of the ‘Categorise FSR’ function? What is the deviation of the current reputation from the desired one?
Source of Data (system, basic user, power user)
<> basic user
Collection Method (system, email, phone)
= system
Relevancy To improve the relevancy of the ‘FSR’ data of the ‘Categorise FSR’ function.
What is the current relevancy of the ‘FSR’ data of the ‘Categorise FSR’ function? What is the deviation of the current relevancy from the desired one?
Fault Related Yes
487
Value-added To increase the added value of the ‘FSR’ data of the ‘Categorise FSR’ function.
What is the current added value of the ‘FSR’ data of the ‘Categorise FSR’ function? What is the deviation of the current added value from the desired one?
Descriptive (Yes/No)
Yes
Timeliness To improve the timeliness of the ‘FSR’ data of the ‘Categorise FSR’ function.
What is the current timeliness of the ‘FSR’ data of the ‘Categorise FSR’ function? What is the deviation of the current timeliness from the desired one?
Age of Data < 2 hours
Completeness To improve the completeness of the ‘FSR’ data of the ‘Categorise FSR’ function.
What is the current completeness of the ‘FSR’ data of the ‘Categorise FSR’ function? What is the deviation of the current completeness from the desired one?
Percentage of populated required fields
> 90%
Amount of Data To improve the amount of data of the ‘FSR’ data of the ‘Categorise FSR’ function.
What is the current amount of data of the ‘FSR’ data of the ‘Categorise FSR’ function? What is the deviation of the current amount of data from the desired one?
Percentage of populated fields
> 80%
Understandability To improve the understandability of the ‘FSR’ data of the ‘Categorise FSR’ function.
What is the current understandability of the ‘FSR’ data of the ‘Categorise FSR’ function? What is the deviation of the current understandability from the desired one?
Fault description is well described (Yes/No)
Yes
F4 - Assign FSR FSR Accuracy To improve the accuracy of the ‘FSR’ data of the ‘Assign FSR’ function.
What is the current accuracy of the ‘FSR’ data of the ‘Assign FSR’ function? What is the deviation of the current accuracy from the desired one?
Collection Method (system, email, phone)
<> phone
Objectivity To improve the objectivity of the ‘FSR’ data of the ‘Assign FSR’ function.
What is the current objectivity of the ‘FSR’ data of the ‘Assign FSR’ function? What is the deviation of the current objectivity from the desired one?
Collection Method (system, email, phone)
= system
488
Believability To improve the believability of the ‘FSR’ data of the ‘Assign FSR’ function.
What is the current believability of the ‘FSR’ data of the ‘Assign FSR’ function? What is the deviation of the current believability from the desired one?
Source of Data (system, basic user, power user)
<> basic user
Reputation To improve the reputation of the ‘FSR’ data of the ‘Assign FSR’ function.
What is the current reputation of the ‘FSR’ data of the ‘Assign FSR’ function? What is the deviation of the current reputation from the desired one?
Source of Data (system, basic user, power user)
<> basic user
Collection Method (system, email, phone)
= system
Relevancy To improve the relevancy of the ‘FSR’ data of the ‘Assign FSR’ function.
What is the current relevancy of the ‘FSR’ data of the ‘Assign FSR’ function? What is the deviation of the current relevancy from the desired one?
Fault Related Yes
Value-added To increase the added value of the ‘FSR’ data of the ‘Assign FSR’ function.
What is the current added value of the ‘FSR’ data of the ‘Assign FSR’ function? What is the deviation of the current added value from the desired one?
Descriptive (Yes/No)
Yes
Completeness To improve the completeness of the ‘FSR’ data of the ‘Assign FSR’ function.
What is the current completeness of the ‘FSR’ data of the ‘Assign FSR’ function? What is the deviation of the current completeness from the desired one?
Percentage of populated required fields
> 90%
Amount of Data To improve the amount of data of the ‘FSR’ data of the ‘Assign FSR’ function.
What is the current amount of data of the ‘FSR’ data of the ‘Assign FSR’ function? What is the deviation of the current amount of data from the desired one?
Percentage of populated fields
> 80%
Understandability To improve the understandability of the ‘FSR’ data of the
What is the current understandability of the ‘FSR’ data of the ‘Assign FSR’ function? What is
Fault description is well described
Yes
489
‘Assign FSR’ function. the deviation of the current understandability from the desired one?
(Yes/No)
Email Receipt Accuracy To improve the accuracy of the ‘Email Receipt’ data of the ‘Assign FSR’ function.
What is the current accuracy of the ‘Email Receipt’ data of the ‘Assign FSR’ function? What is the deviation of the current accuracy from the desired one?
Collection Method (system, email, phone)
<> phone
Objectivity To improve the objectivity of the ‘Email Receipt’ data of the ‘Assign FSR’ function.
What is the current objectivity of the ‘Email Receipt’ data of the ‘Assign FSR’ function? What is the deviation of the current objectivity from the desired one?
Collection Method (system, email, phone)
= system
Believability To improve the believability of the ‘Email Receipt’ data of the ‘Assign FSR’ function.
What is the current believability of the ‘Email Receipt’ data of the ‘Assign FSR’ function? What is the deviation of the current believability from the desired one?
Source of Data (system, basic user, power user)
<> basic user
Reputation To improve the reputation of the ‘Email Receipt’ data of the ‘Assign FSR’ function.
What is the current reputation of the ‘‘Email Receipt’ data of the ‘Assign FSR’ function? What is the deviation of the current reputation from the desired one?
Source of Data (system, basic user, power user)
<> basic user
Collection Method (system, email, phone)
= system
Accessibility To improve the accessibility of the ‘Email Receipt’ data of the ‘Assign FSR’ function.
N/A N/A
Relevancy To improve the relevancy of the ‘Email Receipt’ data of the ‘Assign FSR’ function.
What is the current relevancy of the ‘Email Receipt’ data of the ‘Assign FSR’ function? What is the deviation of the current relevancy from the desired one?
Fault Related Yes
490
Value-added To increase the added value of the ‘Email Receipt’ data of the ‘Assign FSR’ function.
What is the current added value of the ‘Email Receipt’ data of the ‘Assign FSR’ function? What is the deviation of the current added value from the desired one?
Descriptive (Yes/No)
Yes
Completeness To improve the completeness of the ‘Email Receipt’ data of the ‘Assign FSR’ function.
What is the current completeness of the ‘Email Receipt’ data of the ‘Assign FSR’ function? What is the deviation of the current completeness from the desired one?
Percentage of populated required fields
> 90%
Amount of Data To improve the amount of data of the ‘Email Receipt’ data of the ‘Assign FSR’ function.
What is the current amount of data of the ‘Email Receipt’ data of the ‘Assign FSR’ function? What is the deviation of the current amount of data from the desired one?
Percentage of populated fields
> 80%
Understandability To improve the understandability of the ‘Email Receipt’ data of the ‘Assign FSR’ function.
What is the current understandability of the ‘Email Receipt’ data of the ‘Assign FSR’ function? What is the deviation of the current understandability from the desired one?
Fault description is well described (Yes/No)
Yes
491
Appendix E.8 Human Resource Measurement Model
Functions Resource Quality Characteristics
Soft Goals Question Metric Threshold Value
F1 - Classify FSR Help Desk Officer
Domain Knowledge
To improve the domain knowledge of the Help Desk Officer performing the ‘Classify FSR’ function.
What is the current domain knowledge of the Help Desk Officer? What is the deviation of the current domain knowledge from the desired one?
Incident Management Process knowledge Level (none, basic, intermediate, expert)
>= intermediate
Call Type Definition knowledge level (none, basic, intermediate, expert)
>= intermediate
Time Management
To improve the time management skill of the Help Desk Officer performing the ‘Classify FSR’ function.
What is the current time management efficiency of the Help Desk Officer? What is the deviation of the current time management efficiency of the Help Desk Officer to the desired one?
Decision Making Duration
< 5 minutes
Experience To increase the experience of the Help Desk Officer performing the ‘Classify FSR’ function.
What is the current experience of the Help Desk Officer? What is the deviation of the current experience of the Help Desk Officer to the desired one?
Incident Management Experience
> 2 years
F2 - Prioritise FSR
Help Desk Officer
Domain Knowledge
To improve the domain knowledge of the Help Desk Officer performing the ‘Prioritise FSR’ function.
What is the current domain knowledge of the Help Desk Officer? What is the deviation
Incident Management Process knowledge Level (none, basic,
>= intermediate
492
of the current experience of the Help Desk Officer to the desired one?
intermediate, expert)
Business impact knowledge Level (none, basic, intermediate, expert)
>= intermediate
Business criticality knowledge Level (none, basic, intermediate, expert)
>= intermediate
Supported products knowledge Level (none, basic, intermediate, expert)
>= intermediate
Time Management
To improve the time management skill of the Help Desk Officer performing the ‘Prioritise FSR’ function.
What is the current time management efficiency of the Help Desk Officer? What is the deviation of the current time management efficiency of the Help Desk Officer to the desired one?
Decision making duration
< 5 minutes
Experience To increase the experience of the Help Desk Officer performing the ‘Prioritise FSR’ function.
What is the current experience of the Help Desk Officer? What is the deviation of the current experience of the Help Desk Officer to the desired one?
Incident management experience
> 2 years
Prioritisation experience
> 2 years
493
Stockbroking experience
> 1 year
F3 - Categorise FSR
Help Desk Officer
Domain Knowledge
To improve the domain knowledge of the Help Desk Officer performing the ‘Categorise FSR’ function.
What is the current domain knowledge of the Help Desk Officer? What is the deviation of the current experience of the Help Desk Officer to the desired one?
Incident Management Process knowledge Level (none, basic, intermediate, expert)
>= intermediate
General IT (hardware & software) knowledge Level (none, basic, intermediate, expert)
>= intermediate
Supported products knowledge Level (none, basic, intermediate, expert)
>= intermediate
Time Management
To improve the time management skill of the Help Desk Officer performing the ‘Categorise FSR’ function.
What is the current time management efficiency of the Help Desk Officer? What is the deviation of the current time management efficiency of the Help Desk Officer to the desired one?
Decision making duration
< 1 minute
Experience To increase the experience of the Help Desk Officer performing the ‘Categorise FSR’ function.
What is the current experience of the Help Desk Officer? What is the deviation of the current experience of the Help Desk Officer
Incident management experience
> 2 years
494
to the desired one?
Categorisation experience
> 2 years
ORGANISATION C Categories experience
> 6 months
F4 - Assign FSR Help Desk Officer
Domain Knowledge
To improve the domain knowledge of the Help Desk Officer performing the ‘Assign FSR’ function.
What is the current domain knowledge of the Help Desk Officer? What is the deviation of the current experience of the Help Desk Officer to the desired one?
Incident management process knowledge level (none, basic, intermediate, expert)
>= intermediate
ORGANISATION C team structure knowledge level (none, basic, intermediate, expert)
>= intermediate
System owners knowledge level (none, basic, intermediate, expert)
>= intermediate
Team responsibilities knowledge level (none, basic, intermediate, expert)
>= intermediate
Time Management
To improve the time management skill of the Help Desk Officer performing the ‘Assign FSR’ function.
What is the current time management efficiency of the Help Desk Officer? What is the deviation of the current time
Decision making duration
< 1 minute
495
management efficiency of the Help Desk Officer to the desired one?
Experience To increase the experience of the Help Desk Officer performing the ‘Assign FSR’ function.
What is the current experience of the Help Desk Officer? What is the deviation of the current experience of the Help Desk Officer to the desired one?
Help Desk/Service Desk experience
> 2 years
Assigning calls experience
> 2 years
ORGANISATION C call assignment protocols experience
> 1 year
Communication Skill
To improve the communication skill of the Help Desk Officer performing the ‘Assign FSR’ function.
What are the communication skills of the Help Desk Officer? What is the deviation of the communication skills of the Help Desk Officer to the desired one?
Written skills (grammar, spelling, technical etc.) (poor, average, good)
> average
Verbal skills (speaking clearly and effectively) (poor, average, good)
> average
Ability to articulate investigation to date. (poor, average, good)
> average
496
497
Appendix C.9 Non-Human Resource Measurement Model
Organisation C – Non-Human Resource Measurement Model
Functions System Quality Characteristics
Soft Goals Question Metric Threshold Value
F1 - Classify FSR Help Desk System
Suitability To improve the suitability of the Help Desk System performing the ‘Classify FSR’ function.
What is the current suitability of the ‘Classify FSR’ function? What is the deviation of the current suitability from the desired one?
FSR is classified Yes
Accuracy To improve the accuracy of the Help Desk System performing the ‘Classify FSR’ function.
What is the current accuracy of the ‘Classify FSR’ function? What is the deviation of the current accuracy from the desired one?
Subjective evaluation
n/a
Time behaviour efficiency
To improve the time behaviour efficiency of the Help Desk System performing the ‘Classify FSR’ function.
What is the current time behaviour efficiency of the ‘Classify FSR’ function? What is the deviation of the current time behaviour efficiency from the desired one?
Turnaround Time
< 5 minutes
Waiting Time < 5 minutes
F2 - Prioritise FSR
Help Desk System
Suitability To improve the suitability of the Help Desk System performing the ‘Prioritise FSR’ function.
What is the current suitability of the ‘Prioritise FSR’ function? What is the deviation of the current suitability from the desired one?
FSR is prioritised
Yes
Time behaviour efficiency
To improve the time behaviour efficiency of the Help Desk System performing the ‘Prioritise FSR’ function.
What is the current time behaviour efficiency of the ‘Prioritise FSR’ function? What is the deviation of the current time behaviour efficiency from the desired one?
Turnaround Time
< 5 minutes
Waiting Time < 5 minutes
498
Effectiveness To improve the effectiveness of the Help Desk System performing the ‘Prioritise FSR’ function.
What is the current effectiveness of the ‘Prioritise FSR’ function? What is the deviation of the current effectiveness from the desired one?
Error Frequency < 2%
F3 - Categorise FSR
Help Desk System
Suitability To improve the suitability of the Help Desk System performing the ‘Categorise FSR’ function.
What is the current suitability of the ‘Categorise FSR’ function? What is the deviation of the current suitability from the desired one?
FSR is categorised
Yes
Time behaviour efficiency
To improve the time behaviour efficiency of the Help Desk System performing the ‘Categorise FSR’ function.
What is the current time behaviour efficiency of the ‘Categorise FSR’ function? What is the deviation of the current time behaviour efficiency from the desired one?
Turnaround Time
< 1 minute
Waiting Time < 1 minute
Effectiveness To improve the effectiveness of the Help Desk System performing the ‘Categorise FSR’ function.
What is the current effectiveness of the ‘Categorise FSR’ function? What is the deviation of the current effectiveness from the desired one?
Error Frequency < 2%
F4 - Assign FSR Help Desk System
Accuracy To improve the accuracy of the Help Desk System performing the ‘Assign FSR’ function.
What is the current accuracy of the ‘Assign FSR’ function? What is the deviation of the current accuracy from the desired one?
Subjective evaluation
n/a
Reliability To improve the reliability of the Help Desk System performing the ‘Assign FSR’ function.
What is the current reliability of the ‘Assign FSR’ function? What is the deviation of the current reliability from the desired one?
Percentage uptime (%)
> 99.998%
Time behaviour efficiency
To improve the time behaviour efficiency of the Help Desk System performing the ‘Assign FSR’ function.
What is the current time behaviour efficiency of the ‘Assign FSR’ function? What is the deviation of the current time behaviour efficiency from
Turnaround Time
< 1 minute
499
the desired one?
Waiting Time < 1 minute
500
Appendix E.10 Root Cause Analysis Results
Organisation C – First Incident Management Instance
Function F3 - Assign FSR of Incident Management Process
Softgoal Metric Value Satisfied Softgoal 60 - To improve the time behaviour efficiency of the ‘Assign FSR’ function.
Turnaround Time > 10 minutes No
Softgoal 76 - To improve the domain knowledge of the Help Desk Officer performing the ‘Assign FSR’ function.
Incident management process knowledge level
Intermediate Yes
Organisation C team structure knowledge level
Basic No
System owners knowledge level
Basic No
Team responsibilities knowledge level
Basic No
Softgoal 77 - To improve the time management skill of the Help Desk Officer performing the ‘Assign FSR’ function.
Decision making duration > 10 minutes No
Softgoal 78 - To increase the experience of the Help Desk Officer performing the ‘Assign FSR’ function.
Help Desk/Service Desk experience
3 year Yes
Assigning calls experience 3 year Yes Organisation C call assignment protocols experience
3 months No
Softgoal 79 - To improve the communication skill of the Help Desk Officer performing the ‘Assign FSR’ function.
Written skills (grammar, spelling, technical etc.)
Good Yes
Verbal skills (speaking clearly and effectively)
Good Yes
Ability to articulate investigation to date
Good Yes
Softgoal 80 - To improve the time behaviour efficiency of the Help Desk System performing the ‘Assign FSR’ function.
Turnaround Time 1/2 minute Yes
501
Function F3 - Categorise FSR of Incident Management Process
Softgoal Metric Value Satisfied Softgoal 40 - To improve the time behaviour efficiency of the ‘Categorise FSR’ function.
Turnaround Time >10 minutes No
Softgoal 52 - To improve the domain knowledge of the Help Desk Officer performing the ‘Categorise FSR’ function.
Incident management process knowledge level
Basic No
General IT (hardware & software) knowledge Level
Basic No
Supported products knowledge Level
Intermediate Yes
Softgoal 52 - To improve the time management skill of the Help Desk Officer performing the ‘Categorise FSR’ function.
Decision making duration >10 minutes No
Softgoal 53 - To increase the experience of the Help Desk Officer performing the ‘Categorise FSR’ ’ function.
Incident management experience
3 year Yes
Categorisation experience 3 year Yes Organisation C Categories experience
3 months No
Softgoal 56 - To improve the time behaviour efficiency of the Help Desk System performing the ‘Categorise FSR’ ’ function.
Turnaround Time 1/2 minute Yes
Function F3 - Prioritise FSR of Incident Management Process Softgoal Metric Value Satisfied Softgoal 21 - To improve the time behaviour efficiency of the ‘Prioritise FSR’ function.
Turnaround Time > 15 minutes No
Softgoal 33 - To improve the domain knowledge of the Help Desk Officer performing the ‘Prioritise FSR’ function.
Incident management process knowledge level
Intermediate Yes
Business criticality knowledge Level
Basic No
Supported products knowledge Level
Basic No
502
Softgoal 34 - To improve the time management skill of the Help Desk Officer performing the ‘Prioritise FSR’ function.
Decision making duration > 15 minutes No
Softgoal 35 - To increase the experience of the Help Desk Officer performing the ‘PrioritiseFSR’ ’ function.
Incident management experience
3 year Yes
Prioritisation experience 3 year Yes Stockbroking experience 3 months No
Softgoal 37 - To improve the time behaviour efficiency of the Help Desk System performing the ‘Prioritise FSR’ ’ function.
Turnaround Time 1/2 minute Yes
Function F3 - ClassifyFSR of Incident Management Process Softgoal Metric Value Satisfied Softgoal 3 - To improve the time behaviour efficiency of the ‘Classify FSR’ function.
Turnaround Time > 15 minutes No
Softgoal 14 - To improve the domain knowledge of the Help Desk Officer performing the ‘Classify FSR’ function.
Incident Management Process knowledge
Intermediate Yes
Call Type Definition knowledge level
Basic No
Softgoal 15 - To improve the time management skill of the Help Desk Officer performing the ‘Classify’ function.
Decision making duration > 15 minutes No
Softgoal 16 - To increase the experience of the Help Desk Officer performing the ‘Classify FSR’ function.
Incident management experience
3 year Yes
Softgoal 19 - To improve the time behaviour efficiency of the Help Desk System performing the ‘Classify FSR’ ’ function.
Turnaround Time 1/2 minute Yes
503
Appendix E.11 Root Cause Analysis Results
Organisation C – Second Incident Management Instance
Function F3 - Assign FSR of Incident Management Process
Softgoal Metric Value Satisfied Softgoal 60 - To improve the time behaviour efficiency of the ‘Assign FSR’ function.
Turnaround Time > 5 minutes No
Softgoal 76 - To improve the domain knowledge of the Help Desk Officer performing the ‘Assign FSR’ function.
Incident management process knowledge level
Intermediate Yes
Organisation C team structure knowledge level
Basic No
System owners knowledge level
Basic No
Team responsibilities knowledge level
Basic No
Softgoal 77 - To improve the time management skill of the Help Desk Officer performing the ‘Assign FSR’ function.
Decision making duration > 5 minutes No
Softgoal 78 - To increase the experience of the Help Desk Officer performing the ‘Assign FSR’ function.
Help Desk/Service Desk experience
3 year Yes
Assigning calls experience 3 year Yes Organisation C call assignment protocols experience
3 months No
Softgoal 79 - To improve the communication skill of the Help Desk Officer performing the ‘Assign FSR’ function.
Written skills (grammar, spelling, technical etc.)
Good Yes
Verbal skills (speaking clearly and effectively)
Good Yes
Ability to articulate investigation to date
Good Yes
Softgoal 80 - To improve the time behaviour efficiency of the Help Desk System performing the ‘Assign FSR’ function.
Turnaround Time 1/2 minute Yes
Function F3 - Categorise FSR of Incident Management Process
Softgoal Metric Value Satisfied
504
Softgoal 40 - To improve the time behaviour efficiency of the ‘Categorise FSR’ function.
Turnaround Time > 5 minutes No
Softgoal 52 - To improve the domain knowledge of the Help Desk Officer performing the ‘Categorise FSR’ function.
Incident management process knowledge level
Basic No
General IT (hardware & software) knowledge Level
Basic No
Supported products knowledge Level
Intermediate Yes
Softgoal 52 - To improve the time management skill of the Help Desk Officer performing the ‘Categorise FSR’ function.
Decision making duration > 5 minutes No
Softgoal 53 - To increase the experience of the Help Desk Officer performing the ‘Categorise FSR’ ’ function.
Incident management experience
3 year Yes
Categorisation experience 3 year Yes Organisation C Categories experience
3 months No
Softgoal 56 - To improve the time behaviour efficiency of the Help Desk System performing the ‘Categorise FSR’ ’ function.
Turnaround Time 1/2 minute Yes
Function F3 - Prioritise FSR of Incident Management Process Softgoal Metric Value Satisfied Softgoal 21 - To improve the time behaviour efficiency of the ‘Prioritise FSR’ function.
Turnaround Time > 10 minutes No
Softgoal 33 - To improve the domain knowledge of the Help Desk Officer performing the ‘Prioritise FSR’ function.
Incident management process knowledge level
Intermediate Yes
Business criticality knowledge Level
Basic No
Supported products knowledge Level
Basic No
Softgoal 34 - To improve the time management skill of the Help Desk Officer performing the ‘Prioritise FSR’ function.
Decision making duration > 10 minutes No
Softgoal 35 - To increase the experience of the Help Desk Officer performing the ‘PrioritiseFSR’ ’ function.
Incident management experience
3 year Yes
Prioritisation experience 3 year Yes Stockbroking experience 3 months No
505
Softgoal 37 - To improve the time behaviour efficiency of the Help Desk System performing the ‘Prioritise FSR’ ’ function.
Turnaround Time 1/2 minute Yes
Function F3 - ClassifyFSR of Incident Management Process Softgoal Metric Value Satisfied Softgoal 3 - To improve the time behaviour efficiency of the ‘Classify FSR’ function.
Turnaround Time > 10 minutes No
Softgoal 14 - To improve the domain knowledge of the Help Desk Officer performing the ‘Classify FSR’ function.
Incident Management Process knowledge
Intermediate Yes
Call Type Definition knowledge level
Basic No
Softgoal 15 - To improve the time management skill of the Help Desk Officer performing the ‘Classify’ function.
Decision making duration > 10 minutes No
Softgoal 16 - To increase the experience of the Help Desk Officer performing the ‘Classify FSR’ function.
Incident management experience
3 year Yes
Softgoal 19 - To improve the time behaviour efficiency of the Help Desk System performing the ‘Classify FSR’ ’ function.
Turnaround Time 1/2 minute Yes