Reference Models for IT Service Provision - QUT ePrintseprints.qut.edu.au/16047/1/Chris_Taylor_Thesis.pdf · 2.3.5 Example of Reference Model Classifications ... eTOM Business Process

Thesis submitted for the degree of

Masters of Information Technology (Research, IT60)

Centre for IT Innovation

Faculty of IT

Queensland University of Technology

Australia

Reference Models for IT Service Provision

Author: Chris Taylor

Supervisor: Associate Professor Dr Michael Rosemann

Associate Supervisor: Associate Professor Dr Glenn Stewart

Year of Submission: 2003

Masters Thesis Chris Taylor

QUT – Centre for IT Innovation Page i

Key words Reference Model

IT Service Provision

ITIL

Quality of Models

Business Process Management

Knowledge Management


QUT – Centre for IT Innovation Page ii

Abstract The new age, the “Information Age” (Davenport and Prusak 1997) has

increased society’s and businesses’ reliance on Information Technology (IT).

Hence, there is an increasing focus on the management of IT, not only from a

technological perspective but also from a business perspective.

This research, sponsored by REALTECH and the Australian Research

Council, applies one of the modern management approaches, business

process management (Hammer 1990), to the domain IT service provision, by

designing a business process reference model for IT Service Provision.

A reference model is an abstracted depiction of reality that serves as a

standardised or suggestive conceptual basis for the design of enterprise

specific models, usually within a like domain. They are one method of

improving the efficiency and effectiveness of enterprise modelling and can

also be used to standardise communication or capture knowledge.

There is a general lack of theory regarding the classification, design and

quality of reference models. The first part of this thesis attempts to fill these

gaps, by presenting a reference model classification scheme, outlining 7

philosophies for the design of reference models and detailing 2 case studies

on the user-perceived quality of business process reference models.

Reference models and the Business Process Management Lifecycle

(Rosemann 2000) are integrated to show how reference models can be

applied to improve the efficiency and effectiveness of business process

improvement projects.

This reference model theory was then applied to produce a model for domain

of IT Service Provision. Investment in IT has increased to become the largest

single element of capital expenditure (Thorp 1998). Gartner predicted that

organisations will spend over 10% of revenue on IT by 2005 (Haines 2000).

A major input for this model is the ITIL best practice documents (CCTA

2000). The reference model focuses on Incident Management and used

focus groups with participants from several large IT service providers to


QUT – Centre for IT Innovation Page iii

validate the models. The designed reference model is then tested in two case

studies to determine its accuracy and usefulness.

The thesis finishes with a discussion of the designed model, the

effectiveness of the procedural model and provides suggestions for the

design of other reference models. The final chapter provides a summary and

an outlook for further research into the area.


QUT – Centre for IT Innovation Page iv

Table of Contents

KEY WORDS ......................................................................................................................................... I

ABSTRACT...........................................................................................................................................II

TABLE OF CONTENTS..................................................................................................................... IV

LIST OF FIGURES............................................................................................................................VIII

LIST OF TABLES ............................................................................................................................... XI

STATEMENT OF AUTHORSHIP.....................................................................................................XII

ACKNOWLEDGEMENTS ...............................................................................................................XIII

CHAPTER 1: PROBLEM OUTLINE ......................................................................... 1 1.1 Introduction.................................................................................................................... 1 1.2 REALTECH Australia .................................................................................................... 3 1.3 Research Objective and Research Questions ................................................................. 3 1.4 Thesis Structure.............................................................................................................. 4

CHAPTER 2: LITERATURE REVIEW...................................................................... 6 2.1 Introduction.................................................................................................................... 6 2.2 Reference Models ........................................................................................................... 6

2.2.1 Definition ................................................................................................................................. 6 2.2.2 Theoretical Justification ......................................................................................................... 12 2.2.3 Reference Model Lifecycle .................................................................................................... 13

2.3 Classification of Reference Models .............................................................................. 14 2.3.1 Characteristics from Literature............................................................................................... 15 2.3.2 Derived Classification Characteristics ................................................................................... 21 2.3.3 Characteristics from a Review of Reference Models ............................................................. 31 2.3.4 Classification Summary ......................................................................................................... 33 2.3.5 Example of Reference Model Classifications ........................................................................ 35

2.4 Typical Applications of Reference Models ................................................................... 37 2.5 Business Process Modelling ......................................................................................... 39 2.6 Applying Business Process Reference Models ............................................................. 42

2.6.1 Templates............................................................................................................................... 46 2.6.2 Scope Definition and Targeting Suggestion........................................................................... 54 2.6.3 Process Benchmark................................................................................................................ 55 2.6.4 Implementation Guide............................................................................................................ 55 2.6.5 Run Time Information ........................................................................................................... 56 2.6.6 Performance Benchmark and Template ................................................................................. 56

2.7 IT Service Provision ..................................................................................................... 56 2.7.1 Application Service Providers................................................................................................ 58 2.7.2 Taxonomy of IT Services....................................................................................................... 61 2.7.3 IT Services Lifecycle ............................................................................................................. 63


QUT – Centre for IT Innovation Page v

2.8 ITSP Business Reference Models ................................................................................. 65 2.8.1 Desired IT Service Provider BP Reference Model................................................................. 66 2.8.2 Existing Models related to IT Service Provision.................................................................... 67 2.8.3 Perceived Shortfalls in existing ITSP BPRM......................................................................... 81

2.9 Chapter Summary......................................................................................................... 82 CHAPTER 3: RESEARCH DESIGN AND METHOD ................................................ 84

3.1 Introduction.................................................................................................................. 84 3.2 Research Design........................................................................................................... 84 3.3 Focus Group................................................................................................................. 86

3.3.1 Introduction............................................................................................................................ 86 3.3.2 Characteristics........................................................................................................................ 86 3.3.3 Conducting Focus Groups...................................................................................................... 86 3.3.4 Justification............................................................................................................................ 87

3.4 Case Study .................................................................................................................... 88 3.4.1 Introduction............................................................................................................................ 88 3.4.2 Characteristics........................................................................................................................ 88 3.4.3 Conducting Case Studies........................................................................................................ 89 3.4.4 Justification............................................................................................................................ 90

3.5 Chapter Summary......................................................................................................... 90 CHAPTER 4: REFERENCE MODEL QUALITY ..................................................... 91

4.1 Introduction.................................................................................................................. 91 4.1.1 Motivation.............................................................................................................................. 92

4.2 Terminology ................................................................................................................. 92 4.3 Research Question........................................................................................................ 93 4.4 Research Design........................................................................................................... 94 4.5 Quality Framework ...................................................................................................... 95

4.5.1 Quality of Modelling Framework .......................................................................................... 95 4.5.2 Guidelines of Modelling ........................................................................................................ 96 4.5.3 Semiotic Framework .............................................................................................................. 96 4.5.4 Deriving the Quality Framework ........................................................................................... 96

4.6 Case Study Descriptions............................................................................................. 100 4.7 Data Collection .......................................................................................................... 101 4.8 Data Analysis ............................................................................................................. 102 4.9 Findings...................................................................................................................... 102 4.10 Limitations and Conclusions ...................................................................................... 107 4.11 Chapter Summary....................................................................................................... 109

CHAPTER 5: REFERENCE MODEL DESIGN PROCEDURE ................................. 110 5.1 Introduction................................................................................................................ 110 5.2 Reference Model Design Philosophies ....................................................................... 111

5.2.1 Blue Sky Design .................................................................................................................. 112 5.2.2 Design by Choice ................................................................................................................. 113 5.2.3 Baseline Design ................................................................................................................... 113


QUT – Centre for IT Innovation Page vi

5.2.4 Common Practice Design..................................................................................................... 114 5.2.5 Best Practice by Composition .............................................................................................. 115 5.2.6 Design by Abstraction.......................................................................................................... 116 5.2.7 Explicit Alternatives Design ................................................................................................ 118 5.2.8 Design Philosophy Summary............................................................................................... 119

5.3 Reference Model Design Procedural Model .............................................................. 120 5.3.1 Define the Reference Model ................................................................................................ 122 5.3.2 Design .................................................................................................................................. 123 5.3.3 Validate................................................................................................................................ 126 5.3.4 Test ...................................................................................................................................... 126 5.3.5 Select Low-Level ................................................................................................................. 127

5.4 Chapter Summary....................................................................................................... 127 CHAPTER 6: ITSP REFERENCE MODEL DESIGN............................................. 128

6.1 Introduction................................................................................................................ 128 6.2 Define the Reference Model ....................................................................................... 128

6.2.1 Model Purpose ..................................................................................................................... 128 6.2.2 Model Characteristics .......................................................................................................... 129 6.2.3 Modelling Conventions........................................................................................................ 135

6.3 Design and Validate High-Level Process Framework ............................................... 145 6.3.1 Design Philosophy ............................................................................................................... 145 6.3.2 Identify Information Entities................................................................................................ 146 6.3.3 Build .................................................................................................................................... 149 6.3.4 Validate................................................................................................................................ 156

6.4 Select Low-Level Process........................................................................................... 159 6.5 Design and Validate the Low-Level Model ................................................................ 159

CHAPTER 7: REFERENCE MODEL TESTING..................................................... 163 7.1 Introduction................................................................................................................ 163 7.2 Test High-Level .......................................................................................................... 163

7.2.1 Case Study Design ............................................................................................................... 166 7.2.2 Case Study Results............................................................................................................... 167 7.2.3 Limitations and Conclusions................................................................................................ 170 7.2.4 Effect on Reference Model .................................................................................................. 172

7.3 Test Low-Level .......................................................................................................... 173 7.3.1 Case Study Design ............................................................................................................... 174 7.3.2 Case Study Results............................................................................................................... 180 7.3.3 Limitations and Conclusions................................................................................................ 185

7.4 Chapter Summary....................................................................................................... 188 CHAPTER 8: ITSP REFERENCE MODEL OUTPUTS.......................................... 189

8.1 Introduction................................................................................................................ 189 8.2 Model Outputs ............................................................................................................ 189

8.2.1 Level 0 Model – Business Process Framework.................................................................... 189 8.2.2 Level 1 Model: Incident Management – VAC ..................................................................... 195


QUT – Centre for IT Innovation Page vii

8.2.3 Level 2 Models .................................................................................................................... 196 8.2.4 Model Output Summary....................................................................................................... 201

8.3 Methodological Outputs ............................................................................................. 203 8.3.1 Use of Focus Groups............................................................................................................ 203 8.3.2 Bottom-up versus Top-down................................................................................................ 205 8.3.3 Modelling of Process Alternatives ....................................................................................... 206

CHAPTER 9: SUMMARY AND OUTLOOK........................................................... 207 9.1 Thesis Summary.......................................................................................................... 207 9.2 Future Work ............................................................................................................... 213

REFERENCES................................................................................................................................... 217

APPENDICES ................................................................................................................................... 224

Appendix A Quality Case Study Protocol............................................................................. 224 Appendix B Examples of classifications of Levels of Reuse ................................................. 231 Appendix C Survey Forms .................................................................................................... 234 Appendix D Detailed Survey Results .................................................................................... 236 Appendix E Company Profiles ............................................................................................. 237

Citec..................................................................................................................................................... 237 Computer Science Corporation............................................................................................................ 237 Corporate Service Agency ................................................................................................................... 237 Deloitte Touche Tohmatsu................................................................................................................... 238 EDS Consulting ................................................................................................................................... 238 Hitachi Data Systems........................................................................................................................... 239 IBM Global Services Australia ............................................................................................................ 239 Mincom................................................................................................................................................ 239 Parmalat Pty Ltd .................................................................................................................................. 240 Queensland Rail................................................................................................................................... 240 REALTECH AG.................................................................................................................................. 240 Telstra .................................................................................................................................................. 241


QUT – Centre for IT Innovation Page viii

List of Figures Figure 1: Reference Model Lifecycle and Characteristics_________________________________ 14 Figure 2: Chapter 2.3 in relation to the Reference Model Lifecycle _________________________ 15 Figure 3: Chapter 2.6 in relation to the Reference Model Lifecycle _________________________ 42 Figure 4: Business Process Lifecycle ________________________________________________ 44 Figure 5: Business Process Lifecycle and related use of Reference Model ____________________ 45 Figure 6: Types of re-use and parts of the model re-used _________________________________ 46 Figure 7: Using a Reference Model as a True Template __________________________________ 47 Figure 8: Using a Reference Model as a Semantic Foundation ____________________________ 47 Figure 9: Derivation by Customisation _______________________________________________ 48 Figure 10: Derivation by Red-lining _________________________________________________ 49 Figure 11: Derivation by Configuration ______________________________________________ 49 Figure 12: Derivation by Embellishment______________________________________________ 50 Figure 13: Applications as Template _________________________________________________ 52 Figure 14: Scope and Definition and Targeting Suggestions ______________________________ 54 Figure 15: IT services as defined by Benson (2002) _____________________________________ 58 Figure 16: xSP Taxonomy (from Seymore and Edwards 2001)_____________________________ 60 Figure 17: Four layered stratification of the ASP market (from Tao 2001) ___________________ 60 Figure 18: Simplified Taxonomy of IT Services _________________________________________ 61 Figure 19: IT Services Lifecycle ____________________________________________________ 64 Figure 20: EMS’s High level ITIL process model _______________________________________ 69 Figure 21: Examples of inconsistencies in modelling in ITIL documents _____________________ 70 Figure 22: IT Service CMM Methodology _____________________________________________ 71 Figure 23: The IT Service CMM ____________________________________________________ 72 Figure 24: Microsoft Operating Framework ___________________________________________ 74 Figure 25: Garschhammer et al. Service Model ________________________________________ 76 Figure 26: eTOM Business Process Framework - Level 0 Processes ________________________ 78 Figure 27: Corbit Overview________________________________________________________ 80 Figure 28: Research Design and embedded Methodologies _______________________________ 85 Figure 29: Chapter 4 in relation to the Reference Model Lifecycle__________________________ 91 Figure 30: Quality Terminology ____________________________________________________ 92 Figure 31: Relationships between view, purpose, perspective and quality ____________________ 93 Figure 32: RM Lifecycle phase in which the Quality research is based ______________________ 94 Figure 33: Quality Framework for this paper __________________________________________ 98 Figure 34: RM Lifecycle related to the types of economic efficiency________________________ 107 Figure 35: Conclusions that add to or differ from current literature _______________________ 108 Figure 36: Chapter 5 in relation to the Reference Model Lifecycle_________________________ 110 Figure 37: Examples of possible information entities ___________________________________ 112 Figure 38: Baseline Design _______________________________________________________ 114 Figure 39: Common Practice Design _______________________________________________ 115


QUT – Centre for IT Innovation Page ix

Figure 40: Best Practice by Composition ____________________________________________ 116 Figure 41: Design by Abstraction __________________________________________________ 117 Figure 42: Relationship between Benefit vs. level of abstraction __________________________ 118 Figure 43: Explicit Alternatives Design______________________________________________ 119 Figure 44: Proposed BP Reference Model Design Procedural Model ______________________ 121 Figure 45: Depiction of the design step of Relating Information Entities ____________________ 125 Figure 46: Purpose of the developed ITSP Reference Model _____________________________ 129 Figure 47: Interaction of Levels of Abstraction________________________________________ 132 Figure 48: Scope of the ITSP Reference Model ________________________________________ 136 Figure 49: Example of error/non-error process split depictions ___________________________ 139 Figure 50: Example showing removal of trivial event ___________________________________ 140 Figure 51: Combining Mandatory and Optional process paths ___________________________ 141 Figure 52: Example of layout of non sequential VAC steps_______________________________ 143 Figure 53: Dimensions in the ITSP Level 0 view _______________________________________ 144 Figure 54: Model Hierarchy Structure ______________________________________________ 145 Figure 55: Combining Blue Sky and Best Practice Design Philosophies ____________________ 146 Figure 56: Porter's Value Chain ___________________________________________________ 151 Figure 57: Highest level of Porter's Value Chain ______________________________________ 151 Figure 58: ITSP first version ______________________________________________________ 152 Figure 59: eTOM (v2.5) Level 1 processes ___________________________________________ 154 Figure 60: ITSP Second Version ___________________________________________________ 155 Figure 61: Draft of the ITSP Model as presented to the focus group _______________________ 156 Figure 62: Reference Model showing "Customer" object on right _________________________ 159 Figure 63: Example of ITIL text and diagrams ________________________________________ 160 Figure 64: Rosemann’s BPM Lifecycle relationship to Huxley's Target methodology __________ 164 Figure 65: High Level model used for first case study (Core processes only)_________________ 165 Figure 66: Enterprise specific model of first case study _________________________________ 167 Figure 67: Enterprise Specific Model for Case study 2 __________________________________ 169 Figure 68: Level 0 Processes______________________________________________________ 173 Figure 69: Process Groupings of the ITSP Reference Model _____________________________ 190 Figure 70: Level 0 Processes of the ITSP Reference Model ______________________________ 191 Figure 71: Level 2 Value Added Chain for Incident Management _________________________ 195 Figure 72: Business Process Lifecycle and related use of Reference Model __________________ 208 Figure 73: Quality Conclusions that add to or differ from literature _______________________ 209 Figure 74: Proposed BP Reference Model Design Procedural Model ______________________ 211 Figure 75: Level 0 Processes of the ITSP Reference Model ______________________________ 212 Figure 76: Example of possible Interaction Model _____________________________________ 216 Figure 77: Example of High Level of Re-Use Classification (Incident Management)___________ 231 Figure 78: Enterprise model example for medium re-use (Detect Incident) __________________ 231 Figure 79: Reference model example for medium re-use (Detect Incident)___________________ 232


QUT – Centre for IT Innovation Page x

Figure 80: Enterprise model example for low re-use (Record Incident) _____________________ 232 Figure 81: Reference model example of Low Level of Re-Use (Record Incident) ______________ 233


QUT – Centre for IT Innovation Page xi

List of Tables Table 1: Fettke and Loos (1999) Reference Model Classification Scheme.......................................... 17 Table 2: Existing and Proposed Model Characteristic Type Overlaps................................................ 19 Table 3: Classification of Reference Models........................................................................................ 34 Table 4: Example reference model classification of SCOR.................................................................. 36 Table 5: Examples of uses for Business Process Modelling ................................................................ 42 Table 6: Readiness for Use Type and Type of Derivation Required .................................................... 51 Table 7: Traditional Outsourcing vs. ASP (Yaho and Murphy 2001).................................................. 60 Table 8: Desired characteristics for IT Service Provider BP Reference Model .................................. 67 Table 9: ITIL Classification ................................................................................................................. 70 Table 10: IT Service CMM Classification............................................................................................ 73 Table 11: IT Service CMM Classification............................................................................................ 75 Table 12: Garschhammer et al. Classification..................................................................................... 76 Table 13: eTOM v2.5 Classification .................................................................................................... 79 Table 14: CORBIT classification ......................................................................................................... 81 Table 15: Overlap in the Modelling frameworks and proposed quality dimensions............................ 97 Table 16: Citations of Quality attributes from case study interviews ................................................ 103 Table 17: Relationship between Design Philosophy and required Design Steps............................... 123 Table 18: Summary of ITSP Reference Model Characteristics.......................................................... 135 Table 19: Object Types for eEPCs ..................................................................................................... 138 Table 20: Maintained attributes in eEPCs......................................................................................... 139 Table 21: eEPC connection types ...................................................................................................... 139 Table 22: Object Types for VAC ........................................................................................................ 143 Table 23: Connection Types for VAC................................................................................................. 143 Table 24: Maintained Attributes for VAC .......................................................................................... 143 Table 25: Summary of Differences to Reference Model..................................................................... 170 Table 26: Re-Use of models in the CITEC case study........................................................................ 180 Table 27: Summary of Improvements derived from CITEC Models .................................................. 183 Table 28: Re-Use of models in the Pauls case study.......................................................................... 183 Table 29: Summary of Improvements derived from Pauls Models..................................................... 184 Table 30: Sample Results from Survey questions............................................................................... 185 Table 31: Characteristics of an IT Service Provision BP Reference Model ...................................... 202 Table 32: Reference Model Classification Characteristics................................................................ 207 Table 33: Results of the Likert questions comparing the books and models ...................................... 236


QUT – Centre for IT Innovation Page xii

Statement of Authorship The work contained in this thesis has not been previously submitted for a

degree or diploma at any other higher education institution. To the best of my

knowledge and belief, the thesis contains no material previously published or

written by another person except where due reference is made.

_________________

Signature of Author

_________________

Date


QUT – Centre for IT Innovation Page xiii

Acknowledgements Several individuals deserve credit for the work contained in this thesis.

Firstly, and principally, the author would like to thank Dr Rosemann for his

vision, and support throughout the 18 months of the project. The author is

greatly appreciative for the opportunity and guidance provided by Dr

Rosemann, and feels privileged to have worked so closely with such a

person.

Secondly, the work would not have started without the significant contribution

of the industry partner REALTECH and the Australian Research Council. A

special thanks to Wayne Baker and Helena Mendes from REALTECH for

their support throughout.

The author is also very appreciative to Mr Grant Erickson from Telstra who

agreed to be part of the internal review panel.

This work relied heavily on the organisations that provided personnel,

valuable time and expertise to contribute through the various phases of the

research. A special thanks to those organisations (listed in the appendix).

Also thanks to Craig Huxley and Dr Christian Probst for constant feedback,

Dr Glenn Stewart as associate supervisor, Wasana Sedera for the

collaboration on the paper submitted to ACIS 2003, Marit Schallert for

support in the student projects and the rest of the CITI staff and students for

making my time easy and thoroughly enjoyable.

I would also like to thank my family who have supported me throughout this

process, as they have throughout the rest of my life.


QUT Page 1

Chapter 1: Problem Outline

This chapter introduces the problem domain and draws from it a problem

definition. It concludes with a description of the thesis structure.

1.1 Introduction

Recent decades have seen a dramatic shift in most economies away from

the “Industrial Age”. The new age, the “Information Age” (Davenport and

Prusak 1997), involves complex business interactions and activities and has

demanded a trend away from the purely function management approaches

that were popularised by authors such as Frederick Taylor (Taylor 1911). As

we move to the “Knowledge Society”, Taylorism as a management tool has

been replaced, or at least supplemented, with trends such as Knowledge

and/or Information Management (Drucker 1990; Hammer 1990; Davenport

and Prusak 1997).

One method of managing this knowledge or information and the increasing

complexity of the Information Age is to codify “knowledge into [an] abstract

system of symbols” (Bell 1973 p20).

The Oxford English Dictionary Online defines the word “model” as:

“a conceptual or mental representation”

Essentially, an “abstract system of symbols” is a model.

Models have been used ever since man first drew on a cave wall, but

recently, driven by the need to support the previously mentioned changes in

society, have seen increased importance. Starting in the 1970s, the

integration of Information Technology into business and society has

increased the need for Enterprise Models i.e. “all the various designs, models

prepared for analysis, executable models to support enterprise operation”

(Bernus et al. 1998 p18). Enterprise modelling, which is the process of

creating these enterprise models, can be a prohibitively expensive activity.

This is particularly true when an enterprise is starting from scratch (Hars

1993). Fortunately, many organisations and individuals have recognised that

often models can be re-used e.g. (Hay 1996; Bernus 1998). The term used to


QUT Page 2

describe a model that can be, and usually has been designed for, re-used in

several situations is “reference model”. These reference models can

significantly reduce the amount of work required for enterprise modelling

(Schütte 1998). Estimates for the re-use of data models include Silverston,

who predicts that around two-thirds of any particular data model could be re-

used in another situation within a particular industry (Silverston et al. 1997).

Even across industry boundaries there are traditional highly generic activities

such as accounting or inventory, allowing a wide range of varied businesses

to benefit from a relatively few number of reference models (Fowler 1997

p10). One of these generic activities that is been becoming increasing

important to enterprises is Information Technology. Willcocks, Feeny and

Islei argue that effective management of IT resources is paramount to

organisational success (Willcocks et al. 1997).

Investment in IT has increased to become the largest single element of

capital expenditure (Thorp 1998). Gartner predicted that organisations will

spend over 10% of revenue on IT by 2005 (Haines 2000).

This research looks at the intersection of the concepts of re-useable

enterprise models (i.e. reference models) and the provision of IT services. In

particular, this research is focused on the business processes of an IT

service provider (an organisation providing IT services), mirroring the trend

toward process management (Hammer 1990; Davenport 1993; Hammer and

Champy 1993).

This research is part of the parent project entitled “Process-oriented

Administrations of Enterprise Systems” (Rosemann 2002) which is based on

the concept that the same principles of business process management, that

have aided process management in industries such as manufacturing and

retail among others, can be applied to the provision of enterprise system

(synonyms are enterprise resource planning, information systems) services.

The research team consists of Associate Professor Dr Michael Rosemann as

chief investigator, Associate Professor Dr Glenn Stewart, and Mr Craig

Huxley and the author, Chris Taylor. Huxley’s work centred around using the


QUT Page 3

Balanced Scorecard (Kaplan and Norton 1992) to develop a method for

identifying and prioritising the processes on which an organisation should

conduct process improvement activities. His work is outlined in his Masters

thesis (Huxley 2003).

This research project is funded by the Australian Research Council (ARC) in

conjunction with an industry partner (REALTECH).

1.2 REALTECH Australia

REALTECH Australia is a subsidiary of REALTECH AG which has its

corporate headquarters in Walldorf, Germany. The company today is a global

entity with offices and subsidiaries in 11 countries. The Australian subsidiary

was established in 1997 and its headquarters are in Sydney NSW.

REALTECH (www.realtech.com) specialises in development of application

and system management software, with the current product suite named

theGuard! The product suite covers the whole range of IT service provision,

including IT service level management, service support, application and

network management and inventory management.

REALTECH also offer consultancy services in all the areas of IT service

provision with specialisation in complex ERP systems.

Their interest in the research project was to leverage current knowledge and

improve its internal practices as well as the practices of its clients with

respect to IT service provision.

1.3 Research Objective and Research Questions

The research objective for this research is to apply the concepts of

reference models to the IT services domain in order to design a partial

business process reference model for IT service provision.

In reaching this research objective several issues are raised, and form the

research questions of this thesis.


QUT Page 4

The overarching question is:

RQ1. What is an appropriate business process reference model for IT

service provision?

In order to answer this question several methodological questions need to be

answered. They are:

RQ2. What types of reference models exist?

RQ3. How can business process reference models be used for

process management?

RQ4. What characterises the quality of a business process reference

models?

And,

RQ5. How can reference models be produced?

The following pages of this chapter outline the structure of the thesis, which

is aimed at providing answers to these questions.

1.4 Thesis Structure

This thesis is essentially on two topics. Firstly, the driving topic of the thesis

is to explore, and develop where necessary, the ideas and concepts of

reference models in a generic sense, i.e. the answers to the research

questions 2-5. The second, topic is the application of these ideas and

concepts into a specific domain, that of IT service provision in order to

develop a business process reference model for IT Service Provision. The

thesis is structure generally follows this sequence, first the methodological

aspects of reference models then the application of these aspects to the IT

service provider domain.

The thesis commences with the exploration of reference models in a general

sense. This section examines, from a theoretical level what they are, what

defines their quality, how they can be created, and how they can be used.


QUT Page 5

Within this section is the Literature Review, which explores the existing

literature on reference models in general.

The second topic of the thesis, IT service provision, the domain of the

reference model to be designed, is also explored next. The literature on

existing models and taxonomies of IT services is presented in the second

part of the literature review.

Chapter 3 introduces the research methodologies and design which are

employed in this research.

The next two chapters explore concepts and ideas of reference models,

developing theories about the quality and development of reference models,

theories that were not found in the existing literature. Following the

exploration of quality in reference models in chapter 4, chapter 5 provides a

theoretical basis for the development of reference models and a procedural

model for designing reference models is proposed and justified.

The topic of the thesis next becomes focused on the domain of IT service

provision, as the procedural model for reference model design is applied to

develop a partial reference model for IT service provision, which is outlined in

Chapter 6. During this design procedure, the model is tested in several

organisations, which is described in Chapter 7, to provide insight into the re-

use of the reference model and also to identify and integrate improvements.

Following the testing of the models, a discussion follows in Chapter 8. This

chapter discusses both topics, on one hand the IT service provision

reference model itself, and on the other hand provides an evaluation of the

procedure used to derive the model.

Chapter 9 summaries the thesis and main findings and provides a direction

for future work, focusing on the methodological aspects of designing and

applying reference models.


QUT Page 6

Chapter 2: Literature Review

2.1 Introduction

As outlined in Chapter 1, the focus of this research is on reference models

and in particular business process reference models for IT service provision.

This chapter summarises the existing literature regarding the design, use and

purposes of reference models. It also highlights the different types of

reference models as mentioned in the literature, and then looks at the

literature surrounding the domain of this research: IT service provision.

2.2 Reference Models

This section looks at the definition of a Reference Model, the theoretical

underpinnings of reference models and presents a reference model lifecycle

that is used to position the various discussions of the thesis.

2.2.1 Definition

There is no one widely accepted definition of a reference model. The

confusion over the exact meaning of the term means it can be, and has been,

applied to many collections of information. The goal of this section is to arrive

at an integrated definition using various definitions, both explicit and implicit,

found accompanying or describing existing self-titled ‘reference models’.

This discussion begins by examining the words that make up the term in the

dictionary sense.

There are several definitions in the Oxford English Dictionary Online for the

term “reference” the most relevant to its use in the context are presented

here:

“The act or state of referring through which one term or concept is

related or connected to another or to objects in the world; also as

objective reference, and attrib. as reference class, property.

The process by which or the extent to which an individual establishes

a relation with elements in society as a standard for comparing status

and values


QUT Page 7

book, etc. of reference, one intended to be, or suitable for being,

referred to or consulted. for reference, for the purpose of consulting or

being consulted.

a group to which a person may or may not belong but which he,

perhaps subconsciously, refers to as a standard in forming his

attitudes and behaviour

In extended scientific and technical use denoting an object, property,

value, or the like, used as a basis for comparative measurement or

standardization.” Oxford English Dictionary Online

Of particular interest in this thesis are the concepts of comparison,

consultation, and standards.

Similarly the most relevant dictionary definitions of the term “model” are:

“An archetypal image or pattern.

A simplified or idealized description or conception of a particular

system, situation, or process, often in mathematical terms, that is put

forward as a basis for theoretical or empirical understanding, or for

calculations, predictions, etc.; a conceptual or mental representation of

something.

Style of structure or form; design, structural type; build, make.

Of systems, institutions, and other immaterial things.” Oxford English

Dictionary Online

The important concepts here are understanding and prediction, simplicity and

idealisation, and a description. Combining these two definitions in a

dictionary sense could provide the statement that a reference model is a

standard description that allows for comparison. Of course, the definition of a

term using two words is often not as simple as combining the dictionary

definition of the two separate words. Therefore, other definitions are

explored.


QUT Page 8

Several of the more widely known reference models are related to technical

computer system design. Presented here is a selection of definitions of a

reference model with respect to computer system design:

“A reference model is a generic manner to organise and integrate

system components.” (Zwegers 1998)

The ISO-OSI Reference model, one of the most widely known reference

models is an attempt to:

“provide a common basis … while allowing existing standards to be

placed into perspective … [and providing] a conceptual and functional

framework” (Anonymous 1998).

The reference model for XML design:

“provides a set of best practices that define the creation of XML

representations of standard business messages.” (Anonymous 2002

pVII).

In addition to these technically focused reference models, there is an

increasing list of reference models aimed at business processes in relation to

IT systems and also models solely focused on the business aspects, with

little or no relation to the IT supporting them.

Frank briefly defines a ‘generic’ reference model as: a representation of “a

class of domains” (Frank 1999 p.696) and that a reference model is:

“motivated by the search for general structures that can be applied to

numerous instances”. (Frank 1999 p.696)

Biemans continues with this description aspect:

“A reference model represents a system as an organisation in terms of

a structure of relatively independent, interacting, and in terms of the

globally defined tasks of these components.” (Biemans 1990 p.35)

Bernus adds:


QUT Page 9

“[Reference Models] capture characteristics common to many

enterprises within or across one or more industrial sectors.” (Bernus et

al. 1998 p6).

SAP’s R/3 reference model, in part is described as a “graphical depiction of

industry reality”. . The US DoD states that it’s reference model can be used

“when a consistent and extensive … terminology is required” (Anonymous

2001 p7).

Misic and Zhao describe the reference model as a problem solving tool

stating that they are descriptions of:

“the standard decomposition of a known problem domain into a

collection of interrelated parts, or components, that co-operatively

solve the problem” (Misic and Zhao 2000 p484).

This use of a reference model for improvement is also reflected in Mertins

and Bernus, when they say a reference model is a:

“reusable enterprise model of common business processes designed

to improve efficiency and planning of new, or redesigning of existing,

processes.” (Mertins and Bernus 1998 p616).

Helbig pushes the concept of a reference model beyond the mere depiction

of reality into the shaper of reality saying:

“reference models are general models that can be used as a standard

for a whole branch, for a group of enterprises or for certain areas…

they are normative and implicit suggestions for a class of enterprises

they are aimed at.” (Helbig 1999).

This provides a view on reference models that they are suggestive in their

content, providing a picture of what and how something should be.

Rosemann also states that reference models are inherently suggestive, as

they “formalise recommended practices for a certain domain” [emphasis

added] (Rosemann 2002).


QUT Page 10

Combining the aspects of problem solving and standardisation, the process

reference model definition provided in the SCOR Overview Booklet, reads in

part:

“a standard description … a framework of relationships, management

practices that produce best-in-class performance standard.”

(Anonymous 2002 p5).

This definition moves from the merely suggestive nature of a reference

model, to the extreme that a reference model contains the best standard.

Based on the reoccurring themes in Reference Model descriptions and

definitions, the following serves as the definition for this research:

A Reference Model is an abstracted depiction of reality (either

current or foreseeable, that serves as a standardised or

suggestive conceptual basis for the design of enterprise specific

models, usually within a like domain.

The terms “standardised or suggestive” were chosen because they represent

the most balanced view of the mentioned definitions. The words lie between

the extremes of the purely descriptive nature, inferred by words like

“common” (Bernus et al. 1998 p6) or “depiction of reality” , and the assertive

terms such as “best-in-class” (Anonymous 2002) or “recommended”

(Rosemann 2002).

An “enterprise specific model” is a model of a part of, or particular view of, an

enterprise or organisation and the comment “usually within a like domain”

reflects the statements of “for a class of” (Helbig 1999), “a known problem

domain” (Misic and Zhao 2000 p484) and “within or across one or more

industrial sectors” (Bernus et al. 1998 p6).

There are many other terms surrounding “Reference Model” and the next

section examines some of them.


QUT Page 11

Overlapping Terms

Reference Models are also referred to in the literature as Partial enterprise

models, or Type I Reference Architectures. These terms have the same

meaning (Bernus 1998 p7). In the same paper, Bernus also identifies the

terms reusable, paradigmatic and typical models as synonyms.

Other terms that are often used as synonyms for reference model are

Technical Report Type II (Anonymous 2002), Stereotypical models (Chin et

al. 1989), Blueprint (Curran and Ladd 2000) and other terms such as

Framework or Guidelines.

Fettke and Loos also identify universal, generic and model patterns as

synonyms (Fettke and Loos 2003).

The term Architecture is also used with respect to reference models. With

respect to conceptual modelling architecture is defined in computing terms

as:

“The conceptual structure and overall logical organization of a

computer or computer-based system from the point of view of its use

or design; a particular realization of this.” Oxford English Dictionary

Online.

Zachman uses the term architecture as a classification for types of models,

for example the system model-function box in the Zachman framework gives

the example “Application Architecture” (Zachman 1987).

The guide to a reference model designed by the US Department of Defense,

states:

“the [reference] model is not … an architecture … [it] is an aid to

developing architectures”. (Anonymous 2001 p3).

Using the most liberal interpretation of ‘model’ i.e. a simplified description of a

situation (c.f. the definition provided in 2.2.1 of a model), an architecture can

be seen simply as a type of model. Indeed the definition of architecture as

above indicates that the architecture can be an instantiation, (i.e. a


QUT Page 12

realisation), of a conceptual structure. The understanding that a reference

architecture is an instance of a reference model is reflected in (Zwegers

1998):

“A reference model specifies the general structure of the system …A

designer might use a certain reference model to specify an

architecture.”

However, as seen in this extract from (Anonymous), the terms model and

architecture have been used interchangeably:

“A most significant example of a reference architecture in information

systems is the Reference Model of Open Systems Interconnection

(often called the seven layer model) developed by ISO in the 1970’s.

This model has underpinned ...” [emphasis added] p1.

Others have used the term architecture to indicate a framework for possible

model types. This perception is particularly popular in the conceptual

modelling area, as distinct from technology development specifically.

Examples are the Zachman Framework, ARIS, CIMOSA, GRAI/GIM, IEM,

PERA (Bernus 1998 p7).

This thesis does not attempt to create a definition of ‘reference architectures’

and this discussion is only to acknowledge that some uses of the terms have

significant overlap in meaning. The definition provided in the previous section

will constitute a reference model for the purposes of this thesis.

2.2.2 Theoretical Justification

The justification behind a reference model relies partially on the assumption

that total variance of information and the means of expressing it at an

instance level is not completely rational. In other words, it seems simply that

representing every single situation with a different depiction is excessive and

that re-use of some of the depictions is justifiable (Frank 1999). The view

taken is that, either by re-using existing common representations, or by

developing new representations that can be applied in many instances, a

common representation can be formed, at least partially, about any domain.


QUT Page 13

In the words of Frank, “This method of reducing the variance by introducing

new common concepts to handle information would not necessarily cause

dysfunctional effects.” (1999 p696) Frank goes further to say that if this

method of reducing variance, i.e. re-using depictions, were applied correctly

that it could contribute to efficiency.

Indeed the basic concept of re-use and abstraction and generalisation of

information used in reference models is already used in almost every model

or representation. Using a constructivist approach, due to the fact that a

model is simply a complexity reduced snapshot of real world concepts, it

stands to reason that different concepts, stripped of their non-relevant

information, can be generalised and represented singularly (i.e. with one

single symbol or word or concept). Every time this singular representation of

different real-world concepts is applied there exists instances of re-use and

the manifestation of generalisation. It is this same concept of generalisability

and re-use, albeit at a higher-level, that provides the justification for the

creation of reference models.

As defined above a reference model is one tool or method that can be

applied for the re-use of depictions. The next chapter proposes a simple

reference model lifecycle to situate the reader for further discussion.

2.2.3 Reference Model Lifecycle

Although no lifecycle for business process reference models has been found

in the literature the use of a simple lifecycle aids in the discussion of

reference modelling and is presented in Figure 1. It shows the lifecycle of the

reference model, which is simply its Design (to be examined in Chapter 5)

and Use (in Chapter 2.6), and also shows that the reference model has

classification characteristics (in Chapter 2.3), and Quality attributes (which is

examined in Chapter 4).

The proposed lifecycle is simply a tool for discussion in this thesis, but could

be extended to include aspects such as maintenance of the model. Due to

the way the thesis has been structured, which attempts to present existing

theories, then develop and apply them to the ITSP domain, the thesis


QUT Page 14

structure will not follow the reference model lifecycle. Also the research on

the quality of reference models, is designed to provide input into how a

reference model should be designed.

Figure 1: Reference Model Lifecycle and Characteristics

The next section examines the classification characteristics of reference

models.

2.3 Classification of Reference Models

As made apparent by the literature review conducted for this study, varied

collections of information have been described as reference models. It is

helpful when studying a field to provide a system of classification. The

classification of reference models could be useful for a variety of purposes.

For example, an end-user of the reference model could use a list of classified

reference models in order to select the most appropriate for the intended use

of the model. The classification could also aid in the design of new reference

models, by making the relevant characteristics of the model explicit at the

time of design. Similarly a classification scheme could allow for the

identification of ‘holes’ in knowledge and also allow for comparison and

improvement or integration or consolidation of other like models (Fettke and

Loos 2003). The classification scheme could also provide a basis for

comparison of relative quality by allowing models to be compared with others

of the same type. Little work has been done to compare reference models,

Design Reference

Model

Reference

Model

Use Reference

Model

Classification Characteristics

Quality Attributes


QUT Page 15

and in particular provide assistance in the selection of reference models

(Misic and Zhao 2000).

This section focuses identifying the classification characteristics of a

reference model as shown in Figure 2.

Figure 2: Chapter 2.3 in relation to the Reference Model Lifecycle

2.3.1 Characteristics from Literature

This section is focused on providing that classification system, and examines

the different types of a reference model as seen in the academic and industry

literature. There has not been much work on the classification of reference

models, in fact only one work has been found, which is described in detail.

Other work on the classification of information models (or conceptual models)

is described after this. Rather than describe each mentioned characteristic in

detail they are only mentioned, then summarised and grouped into a table,

from which the classification scheme used for this thesis is derived and

explained in detail.

Fettke and Loos

The classification scheme itself is based on Fettke and Loos’ 2003 scheme

(Fettke and Loos 2003). A brief high-level discussion of their classification

scheme is presented here.

Design Reference

Model

Reference

Model

Use Reference

Model


Quality Attributes


QUT Page 16

Fettke and Loos grouped their characteristics according to two dimensions,

specificity and domain dependence. The first dimension describes whether

the classification characteristic is dependent on the context (or domain) of the

model. Domain independent characteristics describe only the formal aspects

of the model, e.g. language, while dependent characteristics define the

domain of the model. Therefore the domain dependence can be either

Dependent or Independent.

Fettke and Loos defined the following classifications; Domain Dependent,

which included Functional Area (e.g. Research and Development, Sales,

Inventory, Production) and also Economic Activity (e.g. Manufacturing,

Trade, Health). The other classification group the Domain Independent

dimension consisted of View (Structure, Behaviour, Function) and Language

(ERM, Function Tree, EPC, Object-Oriented Approach). The second

dimension, describes the Specificity, which is whether the characteristic is of

a group of reference models, or whether the characteristic is of a single

reference model. The specificity of the characteristic can therefore be

“General” or “Specific”. In Fettke and Loos’s paper, this dimension is largely

ignored in their final classification scheme.

Subsequent correspondence with the author (Fettke 2003) indicates that the

reason for this is that examination of Independent-Specific characteristics is

highly dependent on the language selected and that examination of

Dependent-Specific characterisations is highly dependent on the chosen

domain making it difficult to generalise for inclusion in a classification

scheme.

The two aspects of Fettke and Loos’s dimension of Domain Dependence

relate neatly with Lindland et al.’s view of the quality of models, which is splits

the entities surrounding modelling into the model itself, the model domain,

the model language and the model audience (Lindland et al. 1994). Fettke

and Loos’s domain dependent characteristics are related to Lindland et al.’s

“domain”, while domain independent are related to the “language”. There is

no corresponding dimension to the Lindland et al.’s audience in Fettke and


QUT Page 17

Loo’s framework, which is reasonable because the characteristics of a model

are independent of any potential audience.

The classification is summarised in Table 1.

Table 1: Fettke and Loos (1999) Reference Model Classification Scheme

Rosemann 1995

Rosemann’s “Morphologic box of information modelling” in (1995) find

reference) outlines 5 characteristics. They are Description view,

Decomposition Layer, Requirement for validity, Individuality of content and

Level of abstraction.

GERAM

The General Enterprise Modelling concepts defined by Bernus are similar to

the “View” category in the other 2 classification frameworks (Bernus 1998):

“Human oriented concepts cover human aspects such as capabilities,

skills, know-how and competencies as well as roles of humans in the

enterprise organisation and operation…

Process oriented concepts: They deal with enterprise operations

(functionality and behaviour)…

Technology oriented concepts, deal with various infrastructures used

to support processes and include for instance resource models

halla

This figure is not available online. Please consult the hardcopy thesis available from the QUT Library


QUT Page 18

(information technology, manufacturing technology, office automation

and others)” (Bernus 1998 p7).

Rosemann 2002

Rosemann (2002) also discussed the classification of reference models

describing several classifications. Including View, Granularity, Scope,

Internal/External, Availability of Model, Textual explanation, Use of

Guidelines, Benchmark data, Explicit alternative scenarios, User Group,

Purpose.

The authors above often do not give a detailed definition of their classification

characteristics. Using the information and terminology the authors above

have presented, the concepts have been grouped as shown in Table 2.


QUT Page 19

Origin Proposed Characteristic

Type Fettke '03 Rosemann '95 GERAM Rosemann ‘00

Description view

Entity Model Content Views

View View

View

Generic Enterprise Modelling Concepts

Language Formality

(Subsumes) Language

Granularity Level of Detail

Decomposition Layers

State Requirement for validity

Functional Area Functional Area Scope

Internal/External Economic

activity Economic activity

Tool Support Availability of Model

Extended Content

Textual explanation,

Use Guidelines, Benchmark data

Readiness for Use

Explicit alternative scenarios

(Partially) User Group

Purpose

Level of Abstraction

Genericity Dimension

Table 2: Existing and Proposed Model Characteristic Type Overlaps

In Table 2 the proposed set of classification characteristics, shown in the left

column, is compared to the existing literature. The only one not covered by

the proposed new characteristics is Rosemann’s “Level of Abstraction”


QUT Page 20

similar to the dimension of “Genericity” (not shown in table) in the CIM-OSA

framework (Anonymous 1993; René Gaches Year Unknown) or GERAM’s

Genericity dimension and Reyneri’s “Genericity” in (Reyneri 1999). These

concepts are similar to Malone et al.’s dimension of “Type” which indicates

the degree of generality or specificity of the model (Malone et al. 1999).

From the definition of a reference model proposed above in 2.2.1, i.e. a

depiction of reality, then the reference model cannot be a meta-level model

and it cannot be a model with only one intended use (usually a characteristic

of a model of one specific situation as opposed to a generalised model). This

confines a reference model to a certain range of genericity. This could

include a reference model used specifically for one organisation to a

reference model for a generic enterprise. This range of genericity is covered

in the functional and economic activity categories as explained below.

Another classification characteristic that has been proposed for reference

models, and is not shown in the table nor been addressed specifically is

“perspective”. Perspective has been defined as the combination of the target

user group and the purpose of the model (Rosemann and Green 2000).

Purpose can have a many to many (n:m) relationship with the use of the

model. That is a reference model may have many purposes and it may be

put to many uses, with no necessary overlap between the two sets. A

reference model might be designed for developing workflow within an

organisation, but it could be used for training or building an application to

support the workflow. Only the reference model’s tangible and intrinsic

characteristics may be relevant when selecting a reference model. Purpose

is deliberately left out of the classification scheme because it is not an

intrinsic characteristic of the model. The effect of the choice of purpose made

during the design of the reference model, is most evident in the Focus

(Technical, Business, Application) and View (Data, Function, Process,

Resource) characteristics of the resulting model. These characteristics are

discussed in detail below.


QUT Page 21

The target group of the model is similar to the purpose of the model in that

the target group may differ from the actual audience or audiences of the

model. The target group influences the characteristics of the model being

designed, particularly the Focus and the Language formality (Natural, Meta-

Model or Ontological Theory) as discussed below.

2.3.2 Derived Classification Characteristics

The next section outlines the characteristic types then the individual

characteristics proposed within these types, with a short description.

View

The characteristic “View” is already widely discussed in literature (e.g.

Bernus 1998; Rosemann 1998; Fettke and Loos 2003). There are 4 common

views often mentioned in literature as early as 1992 (Curtis et al. 1992)

although they were originally termed “perspectives” although this term has

evolved to now mean the union of the intended audience and the purpose of

a model (Rosemann and Green 2000). The most common views include,

functional, behavioural, organisational and informational.

Functional

The functional perspective describes what activities are performed. Terms

such as tasks or activities are often used when depicting functions. Functions

are often used in both behavioural and resource views, however for the

purposes of this thesis, the functional view is used to denote those models

that only examine the functional aspects of a situation without regard for the

sequencing or organisational or resource implications.

Behavioural

(or Process or Control): The behavioural view captures the rules about

when/why/how functions should occur. It includes rules and often outline

when the function is performed (sequencing, conditions, loops). It includes

concepts such as sequencing, decision paths, conditional branching loops

etc. In other words, the behavioural view defines how functions are employed

in response to a stimulus (Anonymous Year Unknown). Some authors e.g.

(Scheer 1998) put process under this heading, although strictly the process is


QUT Page 22

a combination of the functional and behavioural views. This strict

interpretation is not adhered to in this thesis and the terms behavioural and

process is used interchangeably for the sake of simplicity and adherence to

common usage.

Organisational

(or Resource) This view shows the resources that are involved in the model.

It is often used for human resource planning but could also involve computer

hardware of software components or other consumables.

Informational

(or Data) This view looks at the temporal concept of data or information. It

can be a depiction of the existence of data, how the individual datum relates

to each other and how it is structured. These models are applied to areas

such as database management, content management or knowledge

management.

Dependent on the goals of the model, other views can be added (e.g.

motivation, technical), these 4 however, are the most commonly mentioned in

literature.

Language Formality

From Fettke and Loos, the language describes the modelling technique,

notation or grammar of the model (Fettke and Loos 2003). Numerous

modelling languages exist for any particular view, and, the language of the

reference model is an important consideration particularly, with respect to

using a reference model in an organisation which already has a standard

modelling technique or experience in a particular language.

Reference models, like enterprise specific1 models come in many languages.

To avoid an endless list on languages, the classification scheme presents

only three categories, Natural, Meta-Model and Ontological Theory

1 The term enterprise specific model is used to indicate a model of a specific situation, it is acknowledged that not all of these models is of an enterprise, but most of the models discussed in this thesis is related to an enterprise.


QUT Page 23

describing the formality of the language. Models that are a mixture of the

following are categorised by the most prevalent language type in the model.

Many reference models may not explicitly state that they are built with a

meta-model or ontological theory in mind. In this case the classification must

be made on the appearance of the use of a meta model or theory. Generally

commonly used, “standardised” languages (such as Petri Nets, Event Driven

Process Chains, UML) at least have a meta model.

From GERAM the three language formality characteristics are:

Natural

This characteristic describes models that are written in natural languages.

The most prevalent of these is plain English.

Meta-Model

Models that present, or are obviously based on a formal description of the

modelling technique are called meta-model type models. A meta-model

consists of the grammar, rules and symbols that define the modelling

language. It can be thought of as the description of the technique and syntax

to which a model should conform. This should include models that are only

implicitly based on a meta-model.

Ontological Theory

These models present both a meta-model and define the semantics of the

meta-model. That is, not only does the meta-model define the types of

symbols should be used and how these symbols can be connected, but it

provides a semantic meaning to the symbols and connections. This

effectively creates an explicit map between the real life constructs and the

symbols used to represent them. Typically these languages are presented

built in dedicated modelling tools.

Level of Detail

Similar to Rosemann’s “Decomposition Levels” and Zachman’s “Rows”, the

level of abstraction describes the level of detail that the model shows. It is the

same dimension as Malones’ “Uses/Sub-Activities” (Malone et al. 1999). The

levels are complete, intermediate and task.


QUT Page 24

Complete

The complete level is designed for the highest level conceptualisation. It is

often used in the initial phases of a modelling or systems design project. It

provides the big picture of the concept under review. The complete level

deals with issues such as planning, opportunities and objectives. Broadly

speaking the complete level defines the purpose of the object. Using a

specific type of modelling (business process modelling) as an example, at the

complete level executives outline strategies and goals.

Intermediate

The intermediate level is a step down from the higher complete level

depiction. It provides more detail allowing segmentation of the entity. It shows

how the major components of the system fit together and inter-relate. Again

with the business process model example, at the intermediate level,

management in the business units sets direction for their organizations.

Task

The task level is the level at which further decomposition of the model is

inappropriate and comprises ‘discreet’ or ‘atomic’ units. An example of this

level is the level in application reference models that depict individual

transactions or screens.

Focus

This characteristic is a description of which parts of the domain are of interest

in the model. This characteristic type is an indication of the ‘real-world’

concepts that the model is trying to capture. It can be thought of as an

answer to the question “what is the model of?”. The characteristics provided

are Business, Technical and Application.

Business

A business model’s main goal is to describe a business concept, for example

how accounts should be structured or how business processes are executed.

While business models may be used to build applications or IT infrastructures

the majority of the content is based on issues to do with aspects involving

people and organisations as entities. These would be used by managers or


QUT Page 25

operational staff among many others and often contain some form of

benchmark. An example of this type of model could be the insurance

reference model by KPMG (Scheer 1998).

Technical

A technical reference model’s main goal is to describe industrial, mechanical

or IT related concepts. This could be tangible concepts, such as routers and

computers or machines, or it could be intangible concepts such as

networking protocols. These would be used by technicians, IT staff and those

responsible for design or maintenance of the technical system being

examined. An example of this type is the OSI/ISO Model (Anonymous 2003).

Application

Application reference models are used to describe the functionality of the

specific application being modelled. An application model can be used as a

communication medium between IT staff and end users among other uses.

The application reference model’s usually serve as a tool to facilitate the

implementation of the system, typically an Enterprise System. The most well

known of these is the SAP R/3 reference model, it describes some of the

processes and functions that the R/3 system can support. Other examples

include the Baan or Siebel reference models.

State

Similar to Rosemann’s “Requirement for Validity” this characteristic type

describes exactly what state the model is representing. The two

characteristics given are Common Practice and Best Practice. Over time a

reference model may move between these categories (especially from Best

Practice to Common Practice), just as today’s innovative idea becomes

accepted and widely used. This can be loosely thought of as an answer to

the question “what time is this model depicting?” or “how state of the art is

the concepts in this model?”, with the common practice depicting now and

the best practice depicting sometime in the future. This is slightly different to

Rosemann’s Requirement for Validity because reference models are

developed at a generalised level, and hence company specific concepts,

such as the differentiation between a TO-BE model (i.e. usually the short


QUT Page 26

term goal at the end of a particular project) vs. an Ideal model the ultimate

long term goal, are not appropriate.

Best Practice

The term ‘best practice’ is used to indicate the notion of the ideal end-state

situation, as typically perceived by experts in a particular field. It could be an

existing running system, or a combination of existing solutions and new

ideas. It is used here to indicate the perceived best solution for a particular

problem domain. The term “best-practice” is a highly subjective term, and is

often difficult and usually impossible to prove or disprove the validity of a best

practice claim. Other terms could be “better”, “good” or “accepted” practice.

Best practice incorporates a kind of ideal end state with no constraints on

resources, situations, implementation costs or politics. The best practice

might also be a representation of the minimum standard an organisation

should achieve.

Examples of best practice reference models e.g. ITIL/SCOR. Many reference

models claim to be best practice models (perhaps usually for marketing

reasons), particularly those which are not technical models.

Common Practice

Some reference models are an attempt to map the current practice (i.e.

common practice), for example SAP R/3 reference model, or the reference

model developed for university finances in Germany (Anonymous 2001).

Functional Area

The functional area describes the scope of activity modelled. The term

“functional” in this case refers to Taylor’s functional approach (Taylor 1911).

It describes the vertical types of activities that an organisation undertakes. A

reference model can represent one or many of these functional groups. It is a

domain dependent characteristic type, in that this classification is dependent

on the content of the model and not the representation of the model itself. It

answers the question of “where is this model set?” or “for what scope of

domain is the model valid?”. Again to avoid an almost endless list of


QUT Page 27

possibilities, three characteristics are presented, Function Specific,

Enterprise and Inter-organisational.

Function Specific

A function specific model is when the model scope is limited to a specific

functional area (or multiple defined functional areas). Examples could be

human resources management, financial management, production etc. An

example is (Malone et al. 1999) which focuses on manufacturing.

Enterprise

An enterprise reference model is a depiction of a single organisation for

example the Process Classification Framework (Anonymous). It would

include all the functional areas for an economic activity or other grouping of

organisations under question. An example would be the SAP R/3 reference

model. The Enterprise reference model would be a superset of the functional

models.

Inter-organisational

An inter-organisational reference model captures the group of models that

represent inter-organisational concepts such as the supply chain, customer

relationship, virtual enterprises or communications. These have been

specifically designed to capture the interactions between organisations or

entities. Examples would include the Siebel model for Customer relationship

management or the Supply Chain Operations Reference Model (SCOR). The

Inter-organisational model could be a superset of the enterprise models.

Economic Activity

As proposed by Fettke and Loos (Fettke and Loos 2003) economic activity is

sometimes what could be called “Industry” but has a more defined meaning

with respect to the United Nations’ “International Standard Industrial

Classification of All Economic Activities” (Anonymous 2002). Again this helps

to answer “where is the model set” or “where is the model most applicable?”.

However, instead of focusing on functional classification it focuses on

economic activity. Three characteristics are presented; Organisation Specific,

Economic Activity Specific and General.


QUT Page 28

Organisation Specific

Some reference models are designed for a particular organisation and are

then used to standardise or benchmark internal processes across instances

within the organisation, such as defining the financial reporting across

different regional offices of an international organisation.

Economic Activity Specific

Economic activity specific models are those that are defined for a particular

economic activity, indicating that their use may not be appropriate for use

outside that domain examples include Financial Intermediation, Public

Administration, Manufacturing, Hotels and Restaurants etc. examples would

be the various versions of SAP R/3’s “Industry Solution Maps”.

General

General reference models in this sense are not related to a particular

economic activity, an example being the Process Classification Framework

(Anonymous).

Tool Support

This indicates whether the model is available in a dedicated modelling tool.

The modelling tool is almost always a computer application and tool support

indicates whether the data file for use in this tool is available. The model can

be provided by the model producer, or a third party who takes the original

model and releases a version of the model in their toolset and language. This

can require some interpretation on the part of the third party. Of course some

reference models are not directly supported by any toolset. Similar to the

distribution characteristic type the same content may be offered with any of

the following tool support characteristics.

Producer supplied

These models have been provided in a data file by the producers of the

reference model. For example, the SCOR model supplied by the Supply

Chain Council.


QUT Page 29

Third party supplied

Some models have been replicated (often with a degree of interpretation) into

the language of a modelling tool by a third party, often consultants or tool

vendors. For example, eTOM supplied by IDS-Scheer.

Extended Content

The characterisation describes whether the model comes with any model or

content ‘extras’. These extras are delivered in addition to the core of the

model. Three characteristics for this type are considered Implementation

Information, Run-Time Information and Model Explanation.

Implementation Information

A model exhibiting this characteristic would include guidance on the

implementation of the situation described in the model. This could come in

different forms such as an implementation methodology. Any information that

could be seen as helping the implementation of the situation in the model can

be classified as implementation information.

Run-time Information

This would include information or guidance in the form of case studies or

performance data for benchmarking. Run-time information is any information

that gives the user an extended view of the post-implementation situation or

challenges faced with running the proposed situation. Aspects of any training

aimed at linking the model to real life examples or explaining the content

would be included in this characteristic.

Model Explanation Information

Extended glossaries, meta-models, or explanations about how to read or

interpret the model would be included here. This extended model information

is aimed at facilitating the model understanding. Training in the language of

the theoretical concepts in the model would be included here.


QUT Page 30

Readiness for Use

This characteristic gives an indication of how the reference model could be

derived2 (i.e. transformed into an enterprise specific model) or at least how

the reference model has been designed for derivation. Derivation is the

process of producing the enterprise specific model starting from the

reference model. It is unlikely that any reference model can be used without

some changes, and this characteristic is not an attempt to define whether

work will need to be done adapting the reference model before use; rather it

is an indication about what type of work is required to convert the reference

model into an enterprise specific model.

Single depiction

A model that is characterised as a single depiction depicts with a one to one

relationship to its domain. There are no built-time (or implementation)

alternatives presented and the model is presented in a “ready-to-run” off the

shelf manner after a certain amount of changes to fit the model to the

situation. This type of model has been referred to as a “prototype” model

(Bernus 1998).

Contains variants

A model that contains built-time variants has explicit alternative options for a

single situation, requiring a user to choose one or more of the explicit

alternatives before implementing the model.

Abstract

This type of model is similar to Bernus’s “Abstract” (Bernus 1998) reference

models or Loo’s “Generic Structures” (Loos et al. 1996). These are reference

models that are at a level of abstraction that they require the addition of

enterprise specific detail to produce the enterprise specific model. These

models require that the user “fill-in-the-blanks” (Bernus 1998) or require

2 The term “derivation” is used to describe the process where by a reference model is transformed into an enterprise specific model. It is similar to “adaption” from GERAM (Bernus 1998) or “instantisation” from the CIMOSA modelling framework (René Gaches Year Unknown).


QUT Page 31

mapping to certain specific semantic meanings before they can be used. This

characteristic is related to the “Level of Abstraction” characteristic type. It is

subtly different however, because it is drawn not from the level of abstraction

of the model, but the difference between the level of abstraction in the

reference model and the expected abstraction level of the Enterprise Specific

Models. An “Abstract” model is specifically designed to provide a high level

framework for the development of the enterprise specific model.

2.3.3 Characteristics from a Review of Reference Models

Along with these previously defined characteristics a review of available

reference models reveals there are other important aspects of reference

models. As mentioned earlier this classification was designed in part to aid

selection of reference models in real life projects. With this in mind, a brief

examination of available reference models was conducted and several more

characteristic types have been added to the scheme. These were

Distribution, Ability to Edit, and Currency. For the purposes of classification in

this thesis these new characteristic types combined with the previously

mentioned are complete and necessary.

As above each of the characteristic types are explained then characteristics

are proposed and explained below.

Distribution

This characteristic type describes how the reference model is made

available. The characteristics are public domain, proprietary available for

sale, proprietary available through membership and proprietary not available.

Some reference models are available through multiple sources, for example

ITIL is a public domain reference model, but several third parties claim to

have ITIL modelled in their proprietary languages. These third party supplied

models are proprietary for sale. In this case a single source reference model

may be categorised in several distribution characteristics.

Public domain

A public domain reference model is one that is made freely available to the

public or pay only for the publishing costs.


QUT Page 32

Proprietary not available

This characteristic describes those reference models that are not available

for the public in any form, often these are the intellectual property of

commercial organisations such as consultancy firms who would see that

information as their competitive advantage. Such models may become

available to the clients of such organisations. An example of this is the IT

Service Management reference model from HP.

Proprietary available for sale

These models are available for purchase from the developers or distributors.

An example of such as developer is IDS-Scheer based in Germany.

Proprietary available through membership

These models are available after obtaining membership (usually for a fee)

with an organisation, typically a body representing a particular industry or

area. An example of this method of distribution is the SCOR reference model

which is available to members of the Supply Chain Council.

Ability to Edit

Related to the tool support is whether the reference model is able to be

edited or modified in its original form.

Locked

Locked models are not modifiable in there original form. This would include

reference models that are supplied in hard-copy only, or media such as a

locked adobe acrobat file.

Open

Open models are modifiable in their original form, assuming access to the

appropriate tool is available.

Currency

Currency is an indication of the timeliness of the model content, and whether

the content of the model is updated.


QUT Page 33

Living

Living models are reviewed and updated with a degree of regularity. This can

be done through inputs from users of the models, surveys or other review

mechanisms. Upgrading a reference models faces similar challenges to the

design of new models (Design is addressed in Chapter 5).

Static

These reference models are those that were never updated, they are

released once in a final version.

Discontinued

These models are those that were once living models but the review and

update processes has been stopped. This is particularly evident in several of

the OSI reference models or the TeleSPICE model which received many

updates soon after its release, and has had no updates for several years.

2.3.4 Classification Summary

Presented in Table 3 is the proposed classification scheme showing the

characteristic types drawn from the academic literature as described in Table

1, and the new characteristic types drawn from a review of existing reference

models.


QUT Page 34

Characteristic Type Comb Characteristics

View M Data/ Information

Process/ Behaviour Function Organisational

Language Formality 1 Natural Language Meta-Model Ontological Theory

Level of Detail M Complete Intermediate Task

Focus 1 Business Technical Application

State 1 Common Practice Best Practice

Functional Area 1 Function Specific Enterprise Inter-organisational

Economic Activity (Industry) 1 Org. Specific EA Specific General

Tool Support N Producer supplied Third party supplied Public Domain

Extended Content N Implementation Run-Time Model Explanation

Readiness for use 1 Single depiction Contains variants Abstract

Distribution M Public Domain


Available for purchase

Available through

membership

Ability to Edit 1 Locked Open

Currency 1 Living Discontinued Static

Table 3: Classification of Reference Models

The column marked with “Comb” denotes the allowable combinations of the

characteristics.

“M”: Indicates that any combination may be possible, but at least one (i.e.

1,m)

“N”: Indicates any combination may be possible (including none) (i.e. 0,m)

“1”: The characteristics are mutually exclusive. (i.e. 1,1)

These combinations are a guide only, as it could be argued for example that

related models presented in languages of different formalities are separate

reference models, or simply parts of the single reference model. Also

characteristics of the model may change over time.


QUT Page 35

This scheme simply suggests the relationship between the characteristics

within a particular characteristic type to aid in the application of the

classification framework.

This scheme has been drawn from literature and derived through the author’s

work and may not be exhaustive.

2.3.5 Example of Reference Model Classifications

Supply Chain Operations Reference Model

The Supply Chain Operations Reference Model (SCOR) has been developed

by the Supply Chain Council, a non-profit industry organisation focused on

supply chain issues. It contains descriptions of the processes of a typical

supply chain, based mainly around manufacturing industries. It uses a series

of arrows and boxes with specific naming methods and so falls into the Meta-

Model level of language formality, however there is no meta-model presented

(only implied). The level of sophistication of the modelling technique is very

low.

The nominal focus is on the business process of an organisation, however

the model is really only a functional model, with some dependencies on

information and resources (i.e. inputs and outputs) shown, but no business

rules for how or when the functions are executed. It attempts to highlight best

practice. Due to the nature of its domain the model is an inter-organisational

model, mapping the process through 5 organisations (from the suppliers’

supplier through to the customers’ customer) through a supply chain.

Although it claims to be industry independent the model only makes sense in

a manufacturing or distribution industry (i.e. not a service industry). More

specifically, it is most applicable to high turn over manufacturing or

engineering environments.

The main advantage of this model is the identification and definition of supply

chain performance metrics, giving the model extended “Run-time” content.

The model contains process elements that can be plugged into the model,

hence the model is of the “Contains Variants” Readiness for use type.


QUT Page 36

The model is accessible through membership to the supply chain council,

and comes in two forms, either a document, or in a dedicated tool, the

different versions respectively locked and open.

The model at this stage is living and the description taken from Version 5.0 .

From the description above the following classification Table 4 is derived.

Characteristic Type Characteristics

View Data/ Information


Language Formality Natural Language Meta-Model Ontological Theory

Level of Detail Complete Intermediate Task

Focus Business Technical Application

State Common Practice Best Practice

Functional Area Function Specific Enterprise Inter-organisational

Economic Activity (Industry) Org. Specific EA Specific General

Tool Support Producer supplied Third party supplied Public Domain

Extended Content Implementation Run-Time Model Explanation

Readiness for use Single depiction Contains variants Abstract

Distribution Public Domain



Available through

membership

Ability to Edit Locked Open

Currency Living Discontinued Static

Table 4: Example reference model classification of SCOR

This provides an example of how the characteristics are derived from an

examination of the model. The same straightforward method of assigning

characteristics was applied throughout the rest of the thesis, and will not be

explained again.


QUT Page 37

2.4 Typical Applications of Reference Models

There have been many uses touted for reference models. To provide a

structure for discussion this section is broken into the ‘focus’ characteristic as

described in the previous section. The focus characteristic categorises what

the reference model is describing, and hence can a framework for analysing

how the reference models are used.

Technical Reference Models

One extensive use of reference models has been in the area of information

technology. Technical reference models generally provide a conceptual

framework for development of technical systems. Zwegers states that

reference models “serve as a point of departure for the design of a large

number of systems in a specific application area”. (Zwegers 1998).

Examples of technical reference models include many from the ISO,

including ISO/IEC 11072:1992 Information technology outlining computer

graphics standards or the ISO/IEC 14662:1997 Information technology -

Open-EDI reference model which describes the interfaces and standards of

Electronic Data Interchange. Others include the Workflow Reference Model

(Hollingsworth 1995) which defines the standard interfaces for a workflow

management system.

One of the most commonly referenced technical models is the ISO-OSI

reference model. It is provides a framework for the development of

communication systems and the seven layers depict the different elements

that make transform the communication from the human interaction to the

physical transmission and back up again to the human interface. It is

interesting to note that this is not the backbone of the most commonly used

electronic communication – the Internet (which uses TCP/IP). Despite it not

actually being widely used the reference model’s ability to be able to

effectively and simply define a complex situation has made it popular. This

highlights one of the uses of a reference model, to display complex ideas in

such a way that it is easily understood and conceptualised.


QUT Page 38

What these reference models have in common is that they attempt to provide

an accepted conceptual or technical standard. This standard ensures that the

products developed under the standard can fit neatly into their respective

roles. They act as input for requirements engineering ensuring that vendors’

products conform to the relevant standards.

Application Reference Models The use of reference models is not only confined to the technical side of IT.

Recently several application reference models have been proposed that deal

with how IT systems can be used, particularly business process models of

enterprise systems (e.g. SAP R/3, Siebel or Baan Reference Models).

One of the major aims of application reference models is to aid with the

configuration and implementations of the applications they describe. They

help to align the application to the business requirements and can be used to

describe the supported business processes, data structures, architectures or

configuration alternatives of the applications. Typically the process reference

models of application models describe the human-application interface of the

application.

Application reference models also include models of business or human

interactions which are used to design or configure IT systems. Examples of

this type of reference model can also be found in the area of web services

and e-market places.

Business Reference Models

Business reference models are mainly focused on describing business

concepts, such as business processes, structures, financial arrangements

etc. An example is the Process Classification Framework (Anonymous) which

provides a generic functional decomposition for a commercial operation, or

the teleSPICE reference model (Emam et al. 1998; Anonymous 2002) which,

in part, describes the processes one should complete when developing

software.

Business Reference Models are useful to:


QUT Page 39

• Communicate “best/common/accepted” practices

• Structure a performance measurement framework

• Encourage reuse in multiple instances and consistency in model

efforts

• Provide guidance or a template for modelling efforts

• Facilitate the classification, evolution and comparability of models by

creating a standard terminology

They provide assistance in

• Business Process Management (BPM)

• Knowledge Management

• Process Benchmarking and Performance Measurement

(Anonymous 1998; Bernus et al. 1998; Curran et al. 1998; Lowe and Webby

1999; Misic and Zhao 2000; Kaplic and Bernus 2001; Anonymous Year

Unknown)

As described in Chapter 1, of particular interesting in this research is

business process modelling and business process reference models. The

next sections look into both of these areas.

2.5 Business Process Modelling

A conceptual model is a simplified depiction of an extraction of reality (Curtis

et al. 1992). The information presented in the model is, in the model creators’

opinion, all the relevant information needed to fulfil the purpose of the model

(Lindland et al. 1994; Davis 2001). Ideally the model should contain only the

minimum required in order to fulfil its purpose and hence “excludes much of

the world’s infinite detail” (Curtis et al. 1992). This is done in two steps, firstly

minimising the scope of the model, focusing on only the relevant objects, and

secondly by depicting this defined scope in a minimalistic manner. By doing

this it would comply with Albert Einstein’s suggestion to “make everything as


QUT Page 40

simple as possible, but not simpler” (exact source unknown). Modelling in

one form or another has taken place since the first caveman drew on the

wall. Several formal modelling techniques were developed with the

introduction of IT, as precise definitions are needed when working in the field.

Data modelling was one example that many organisations used.

In the 1990’s many organisations implemented large and complex enterprise

systems, including Enterprise Resource Planning packages (ERP). The

traditional focus on modelling data flows and transformations was not

sufficient to capture the increased use of IT beyond data processing into

areas of communications and co-ordination (Curtis et al. 1992). At the same

time, popularised by Hammer in 1990 (Hammer 1990), the change from

Taylor’s (Taylor 1911) scientific management principals to the process

perspective marked a dramatic shift in business management.

This deficiency in modelling techniques and the contemporary popular focus

on BPR increased the need for a process modelling. A process (used often

synonymously with business process) can be defined as:

“a self contained, temporal and logical order of those activities, that are

executed for the transformation of a business object with the goal of

accomplishing a given task” (Green and Rosemann 2000).

“the definition of the tasks and the sequence of those tasks necessary to

deliver a business function” (Davis 2001)

“a set of partially ordered steps intended to reach a goal” Humphrey and

Feiler (1992) in (Curtis et al. 1992), or

“a structured, measured set of activities designed to produce a specified

output” (Davenport 1993).

Hence process modelling (or business process modelling, BP Modelling) can

be defined as:

“the capture, documentation and analysis of [business processes]” (Davis

2001 p2), or


QUT Page 41

“an abstract description of an actual or proposed process that represents

selected process elements that are considered important to the purpose of

the model” (Curtis et al. 1992 p.76).

The working definition for this thesis is:

Business process modelling is the activity of capturing and

analysing the important aspects of a business process.

In the early stages of process modelling the focus was on the use of models

to describe and implement IT based solutions. Business process modelling

differs significantly from the more traditional modelling techniques used in the

field of IT because “many of the phenomena modelled must be enacted by a

human rather that a machine” (Curtis et al. 1992 p77). Today, BP Modelling

is seen as part of Enterprise Modelling, and related upper-CASE (computer

aided software engineering) tools allow the integration of process design at a

conceptual level with the coding into Enterprise Systems, for the enactment

of these processes, and ultimately the monitoring of these processes (van

der Aalst and Kumar 2001).

Even though some models produced included both semi-manual and IT

executed steps the main emphasis was on the IT system, sometimes

excluding the solely manual steps. As BP Modelling matured the advantages

of using it in areas outside the IT domain became apparent. Today BP

Modelling has been used to map the entire process, as originally proposed

by Hammer, regardless of whom or what executes the function.

Various uses for BP Modelling have been summarised in Table 5 adapted

from (Rosemann et al. 2003).

Improvement of internal business processes

Improvement of collaborative business processes

Software development Design of Enterprise Architecture

Business process documentation Change Management

Workflow management Training


QUT Page 42

Table 5: Examples of uses for Business Process Modelling

While parts of the remainder of this thesis may be applicable to reference

models in general, the term reference model is used to indicate business

process reference models in particular from now on.

2.6 Applying Business Process Reference Models

This section summaries and extends the literature with respect to the use of

business process reference models, as highlighted in Figure 3. In particular it

focuses on using business process reference models in Business Process

Re-engineering (BPR) projects, one of the major uses for business process

reference models. The section answers the third research question:

“How can business process reference models be used for process

management?”

Figure 3: Chapter 2.6 in relation to the Reference Model Lifecycle

Very few published works have mentioned how to apply a reference model.

Two exceptions, however, are brief mentions in Schlagheck and Scheer.

Schlagheck 2000 (in Fettke and Loos 2003) details four steps in the process

of applying a reference model:

Design Reference

Model

Reference Model

Use Reference

Model


Quality Attributes


QUT Page 43

1. Problem Definition

2. Requirements definition

3. Reference model selection

4. Enterprise-specific model construction

Scheer (1999 p.94), while describing the steps used for individualising

reference models, gives 4 steps:

1. Determining the Vertical Market

2. Determining the Business Processes

3. Selecting the Reference Models

4. Adapting the Reference Models

These steps do not provide details on exactly how the reference model

should be used (other than the generic “adapt”) nor do they link it to any of

the activities in which modelling is embedded. Modelling is seldom an ends in

itself, but rather a means to some other ends. A common end is business

process management. Rosemann’s Business Process Lifecycle (Rosemann

2000), shown in Figure 4, outlines the steps in for business process

improvement (BPI) and business process management (BPM).

The remained of this section is an extension to the generic outlines provided

above on how to apply business process reference models.


QUT Page 44

Figure 4: Business Process Lifecycle 3

Similar lifecycles or process steps can be found in McGowan and Bohner

(1993) and van der Aalst et al. (2003).

This lifecycle is used to discuss specific applications of process reference

models and also how they can be applied in each instance. To examine how

reference models can be used in the lifecycle, the applications discussed in

2.4 can be matched to the lifecycle steps.

Figure 5 shows how a reference model can be used in the business process

lifecycle. On the left is the process lifecycle, the middle column shows the

uses of the reference model and on the right are the steps that are needed to

select the appropriate reference model. Also shown in this figure are the sub-

sections of this chapter that describe the individual applications in more

detail.

3 Note: The original step of “process identification” has been broken into “process identification” and “process targeting” to aid in the discussion of the application of business process reference models.

Process Identification

Process Targeting

AS-IS Modelling

Analysis

TO-BE Modelling

Process Implementation

Process Execution

Monitoring/Control


QUT Page 45

Figure 5: Business Process Lifecycle and related use of Reference Model

The following sub-sections describe the types of uses (Template, Scope

Definition and Targeting, Process Benchmark, Implementation Guide, Run

Time Information and Performance Benchmark) in more detail.

It should be noted that at present not many reference models have the

maturity to be used in all of the above mentioned ways. Indeed for a single

reference model to be able to be used in all the above ways, it would require

a significant investment in the model design.

Firstly the application as a template (high-level, AS-IS and TO-BE) are

described, secondly use as a process identification tool is examined followed

by the use as a process benchmark, as an implementation guide and finally

as a performance benchmark.

Select Reference Model

Process Identification High-Level Template (2.6.1)

Process Targeting Scope definition/ suggestions (2.6.2)

AS-IS Modelling AS-IS Template (2.6.1)

Analysis Process Benchmark (2.6.3)

TO-BE Modelling TO-BE Template (2.6.1)


Implementation information (2.6.4)

Process Execution

Monitoring/Control Run Time

Information/Performance Benchmark (2.6.6)


QUT Page 46

2.6.1 Templates

The most commonly discussed use for reference models is a template or

starting point for the design of enterprise specific models (Scheer 1994;

Mertins and Bernus 1998; Scheer 1999).

This subsection firstly examines the which parts of the reference model can

be re-used as a template, secondly it describes how the models can be

derived from the reference model, the derivation methods, and thirdly it

examines the individual applications of use as a template in the BPR

lifecycle.

Reusing Semantics and/or Syntax

A reference model can be used as a template in three ways. Quite simply, its

semantics and syntax can be re-used or only one or the other can be used.

Type of Re-use

Part for re-use True Template Semantic Foundation

Modelling training aid

Semantics X X Syntax X X

Figure 6: Types of re-use and parts of the model re-used

The first and second cases have been named True Template and Semantic

Foundation, and are examined next. The third type, termed Modelling

Training Aid, has only limited application for training on how to model using a

specific modelling technique and is not discussed further.

True Template

The first option, the true template, starts with the reference model and

directly edits it to produce the required enterprise specific model, using both

the syntax and semantics of the reference model as shown in Figure 7. To

use a reference model as a True Template it must have the “ability to edit”

characteristic of “open”.


QUT Page 47

Figure 7: Using a Reference Model as a True Template

Semantic Foundation Only

Alternatively, the reference model can serve as a semantic foundation only,

providing or supplementing the designers’ knowledge about the domain. This

second semantic-only method would be required if the desired enterprise

specific model was in a different language to the reference model and would

also necessitate interpretation of the reference model as depicted in Figure 8.

Figure 8: Using a Reference Model as a Semantic Foundation

In either case, whether re-using the syntax and semantics or semantics only,

several derivation methods can be employed.

Derivation Methods

Four methods for derivation are described below.

Reference Model Enterprise Specific Model

Derivation

Red hexagon

Blue Circle

Green Square

Yellow Cross


Derivation


QUT Page 48

Customisation

The first is “Customisation” graphically explained in Figure 9. This involves

changes to the model including the addition, deletion and/or modification of

certain parts of the reference model. This could involve changing objects,

names or layout of the model or adding completely new parts of the model.

Customisation is shown in Figure 9.

Customisation might be as simple as changing the name of the reference

model to reflect the organisation using it.

Figure 9: Derivation by Customisation

The above picture shows how the majority of the reference model is reused

with small changes.

Red-lining

A sub-set of the Customisation type of derivation is Red-lining. “Red-lining” a

term previously used to describe the process of deriving the enterprise

specific model from the SAP reference model e.g. Curran et al. (2000), is

used to describe the process where parts of the model are deleted, but not

added, during the derivation process. The rest of the model is used without

any modifications.


Derivation


QUT Page 49

Figure 10: Derivation by Red-lining

Configuration

Figure 11 shows the Derivation by “Configuration”, this requires that the

reference model has explicit configuration points (i.e. its “Readiness for Use”

characteristic is “Contains Variants”). This is similar to the Red-lining

derivation, but in this case a reference model user is forced to make a

decision between two (or more) alternatives.

Figure 11: Derivation by Configuration

Figure 11 above shows how the reference model user selects between

explicit alternatives, in this case the red hexagon and not the blue circle, and

the aqua square and not the yellow cross.


Derivation


Derivation

OR

OR


QUT Page 50

Embellishment

The third type of derivation is “Embellishment”. Figure 12 depicts the

Embellishment step, where extra detail is added to the reference model in

order to make it suitable for the enterprise specific model. Whether a model

requires embellishment is closely related to the characteristic of Level of

Abstraction of the reference model. The embellishment could also involve not

only adding higher level of detail but also other information such as different

views or performance, implementation or other data.

Figure 12: Derivation by Embellishment

In figure 12 the basis high level nature of the reference model has been

reuses, but the enterprise specific model has added detail at a lower level.

Many real life derivations will probably be a combination of the above

derivation methods, dependent on the characteristics of the reference

model/s that has/have been selected and the requirements of the enterprise

specific model. Generally the characteristics of the reference model

(specifically the “Readiness for Use” characteristic described in 2.3.4)

requires different combinations of the derivation methods as shown in Table

6. The “yes” and “no”s indicate which particular derivation method/s is/are

required for the type of reference model being used.

Although theoretically possible, the use of a reference model without a

degree of customisation is not considered here, because in practice it would

not occur. The customisation in the extreme case would require only the

Reference Model

Derivation

Enterprise Specific Model


QUT Page 51

changing of the name of the reference model to suit the individual situation in

which it is used.

Derivation Method Required Customisation Red-lining Configuration Embellishment

Single depiction Yes Yes/No No No

Contains variants Yes Yes/No Yes No

Rea

dine

ss fo

r Use

Ty

pe

Abstract Yes Yes/No Yes/No Yes

Table 6: Readiness for Use Type and Type of Derivation Required

Having defined above what parts of the model can be used as a template

and linking this to the types of derivation, the next step looks at the individual

applications of the reference model as a template. A reference model can be

used as a template (in any of the ways described above) three times in the

process management lifecycle, once for the identification of processes, which

would use the higher level abstractions of the reference model, again when

modelling the more detailed AS-IS processes and thirdly for the development

of the TO-BE models.

Applications of Reference Model as a Template

The three applications as a template are highlighted in Figure 13.


QUT Page 52

Figure 13: Applications as Template

Process Identification

Firstly, in the case of the higher level model reference model being used for

process identification, the goal is simply to provide a structure and scope for

the targeting phase. It provides a starting point which an organisation can

modify to suit its own terminology and process structure at a high level

(Huxley 2003 p92-3). Once this is complete the results can be used as a

comprehensive documentation of the processes in which an organisation is

operating, i.e. it has identified the processes. This is the input to the targeting

phase, which questions on which processes effort should be expended for

process improvement.

Rosemann’s original “Process Identification” step has been split into pure

identification, essentially the cataloguing of the organisation’s processes, and

process targeting, which takes this list of processes and selects those that

will go through the remainder of the lifecycle steps in a particular cycle. This


Process Identification High-Level Template

Process Targeting Scope definition/ suggestions

AS-IS Modelling AS-IS Template

Analysis Process Benchmark

TO-BE Modelling TO-BE Template


Implementation information

Process Execution


Information/Performance Benchmark


QUT Page 53

is done to more accurately show the use of the reference model in these two

steps.

The reference models most suited for this identification and targeting stages

are the economic activity specific business process models at a “Complete”

Level of Detail, as they depict the high level processes that are common

across the industry being examined.

AS-IS Process Modelling

Again the model can be used as a template or a guide in the AS-IS modelling

phase. At this stage the mid-level models can be used to segment the

modelling work and act as a framework for the lower level detail. The lowest

level detail in the reference model can be used as a semantic check,

ensuring that modellers have a basic understanding of the process. This is

important as it allows the enterprise modellers, who may lack domain

knowledge, to be able to probe the process owners and executors to ensure

that the AS-IS model is accurate. It is proposed that this understanding of the

domain provided by the reference model can significantly improve the

developed models, particularly when the modellers are not experts in the

particular domain. A reference model that would be useful at this stage could

be either an Intermediate or Task level model of the specific economic

activity or of a specific functional area. Depending on the maturity of the

processes being examined a common practice (for immature organisations)

or best practice (for mature organisations) would be more appropriate as they

would more closely reflect the AS-IS situation.

TO-BE Process Modelling

Assuming that process improvement is one of the goals of the modelling

project and that the reference model chosen is of the type “best-practice”, the

reference model could be used as a template for the TO-BE model

development. If the model was ‘single depiction’ then limited work would

need to be done on the reference model to transform it into the TO-BE

model.


QUT Page 54

2.6.2 Scope Definition and Targeting Suggestion

This section deals with the application of the reference model as a scoping

and or process targeting suggestion tool as shown in Figure 14.

Figure 14: Scope and Definition and Targeting Suggestions

Used in the Process Targeting Step, a reference model, either implicitly or

explicitly, suggests where an organisation should focus its process

improvement activities, as alluded to in Huxley (2003). He states that, when

using a reference model for process identification and targeting, processes

may not be recognised and that this lack of recognition could be due to the

low importance of the processes. (Huxley 2003 p.92-3).

The choice to include something as a core, support or strategic activity, the

naming or hierarchical positioning of a process in the model, can all implicitly

suggest the reference model creators’ perception of the importance of a

process.









Process Execution




QUT Page 55

Additionally, the extended information included with a model might include

suggestions about the importance or criticality of processes. For example, a

study may suggest “critical” processes for a particular industry, or may

provide data on past improvements in a particular process in other

companies that could be extrapolated into the current situation to aid the cost

benefit analysis. A list of critical processes could be linked to strategic

directions, for example in a consumer market a particular vendor may choose

to be a high-end market niche player, the reference model may contain

information that suggests that, when using this strategy, marketing or quality

control processes are highly critical. The reference model could also

incorporate methodologies to determine the most critical processes for

example by showing cause and effect relationships between processes, or by

linking processes to strategy, goals or industry standard key performance

indicators (KPIs).

2.6.3 Process Benchmark

The reference model can be used as a process benchmark. Particularly if the

reference model was used a true template as described above, the

comparison of a reference model ‘Best Practice’ with the AS-IS models can

be relatively straight forward, allowing a gap analysis. The use of process

models for benchmarking can make assessment very specific and can

highlight opportunities for improvement that other methods may miss

(McGowan and Bohner 1993). This gap analysis can then aid the process

issue identification and therefore provide suggestions for improvement which

can be incorporated in the TO-BE modelling phase. This step would be most

beneficial if the reference model chosen was a ‘best practice’ model,

although the comparison of the AS-IS to a ‘common’ practice reference

model would still highlight potential areas for analysis, particularly if

standardisation was the key driver for the business process re-engineering.

2.6.4 Implementation Guide

As can be seen in the classification scheme, some reference models include

information on how to implement the proposed processes, including

information such as change management information, previous experiences


QUT Page 56

and lessons learned, or models such as procedural models with steps for

implementation.

2.6.5 Run Time Information

Models that contain run-time information such as including for example

advice on staffing, technologies, reoccurring problems and methods for

overcoming them, can be used in the Process Execution phase of the

Business Process Lifecycle.

2.6.6 Performance Benchmark and Template

More comprehensive and ‘extended’ reference models can suggest relevant

performance metrics and even provide comparative data that may have been

collected in other instances. This Key Performance Indicator (KPI) template

can then be modified to suit the individual project to assist the identification of

performance measures, and then at run-time it can assist with the monitoring

and controlling phase of the BPM lifecycle.

2.7 IT Service Provision

As described in Chapter 1, process modelling has been used in the

application areas of IT as part of the analysis of key business processes

however has had only limited use in IT service provision.

Those models that do exist, focus on the early stages of IS and IT systems

lifecycle, for example in the selection or design, and implementation steps

(Gulla and Brasethvik 2000). Examples of models that suit these purposes

are the software spiral model, the SAP R/3 Implementation Guide, ValueSAP

or the Rational Unified Process and many implementation methodologies

from the consulting firms.

An area which is underdeveloped in terms of methodological support is the

administration, maintenance and support of the system. As the large number

of systems implemented in the late 1990’s mature, the support and benefits

realisation of these systems has become more important. Indeed in terms of

lifecycle costs, Gartner research shows up to 80% (Anonymous 2003) is

incurred the after the purchase of an IT system. The importance of


QUT Page 57

maximising the benefits and minimising the costs of such IT investments is a

major motivator for this research. Not only is the efficiency and cost of the

provision itself important, but the effectiveness of the delivery can have

profound effects on the business processes it supports. A poignant reminder

of organisation’s reliance on IT is highlighted by the recent collapse of the

Australian Telco One.Tel due to a fault in its billing applications (Barry 2002).

This section of this literature review looks at the specific domain of the IT

service provider. It also examines some of the existing models for IT service

provision. This thesis focuses on outsourcing of IT, and organisations whose

core business is IT service provision. IT outsourcing has been defined as

passing IT functions previously performed in-house to external parties (Gupta

and A 1992). At the turn of the 21st century the growth rate for IT outsourcing

worldwide was around US$100 billion and growing at around 16% p.a.

(Lacity and Willcocks 2000). A recent IDC report indicates that in Australia

alone the IT Outsourcing industry is worth over $AU10b (Benson 2002).

Sriram quoted Garter Dataquest (July 2002) as predicting that the Australian

IT services industry will grow up to $US16.7b by 2005 (Sriram Year

Unknown).

The focus on the IT outsourcing arrangement as the business model of

delivering IT services was chosen because of the increasing popularity of IT

outsourcing and the expectation that IT outsourcers perform better than in-

house service providers, and provide an opportunity to clarify and enforce the

terms of the service as well as penalties for breaches (Lacity and Willcocks

2000).

This focus, however, does not mean that the findings or the reference model

would be entirely unsuitable for internal service provision. Indeed it has been

argued that internal service providers should, to a certain extent, model

themselves on external providers to ensure efficiency, accountability and

effectiveness (Ross et al. 1999).

Most of the literature on IT services focuses on outsourced IT services. It has

been defined as:


QUT Page 58

“the contracting by an organisation with a third party for the

management and enhancement of ongoing operations for all or part of

its IT infrastructure, IT functions, business processes, or business

solutions. Outsourcing involves a fixed-term, contractual arrangement

that may involve the transfer of assets or people.” (Benson 2002)

The actual services that constitute IT Services are show in Figure 15.

Figure 15: IT services as defined by Benson (2002)

As noted in the same report IS Outsourcing makes up 38% of the IT services

market. The range of outsourced IT services providers spans from the most

basic such as network service providers, to the more business-oriented types

such as business service providers. The following examination of the IT

services market allows the reference model to be positioned.

In order to present a taxonomy of IT outsourcing in which to position the

reference model, the Application Service Provision (ASP) market, a subset of

the IT services market is examined in the next section. The ASP market

layering is extrapolated to the IT services domain because much literature

has been produced about the ASP, and how the market is segmented.

2.7.1 Application Service Providers

In the mid 1990’s the concept of Application Service Provision (ASP) was

introduced. It is a form of applications outsourcing. Much literature

particularly industry press was devoted to explaining how ASP was

positioned in the market.

Although the idea is simple, “ASP” however is a somewhat confusing term

(Dunn 2001; Swift 2001). The definition and scope of available ASP services

continues to evolve, muddying the term (Boyle 2002).

halla



QUT Page 59

The idea behind Application Service Provision (ASP) is not new. ASP is a

type of IT outsourcing. As early as the 1960’s traditional bureau service has

offered companies access to payroll processing (Bennett and Timbrell 2000;

Perdue 2000; Swift 2001). Other examples of outsourcing include the “time-

sharing” concept in the mainframe days of early computing (Perdue 2000;

Swift 2001).

Some authors specify that ASPs deploy, host and manage “packaged”

(Zimmerman 2002) or “off-the-shelf” (Bennett and Timbrell 2000)

applications, while others include in ASP those who develop or host specially

developed or unique software (Swift 2001). Other ASP services can include:

implementation, configuration, maintenance, support and application hosting

(Bennett and Timbrell 2000).

Other authors specify that the ASP physically host the hardware and client

data (Swift 2001; Anonymous 2002) which is essentially Application Hosting.

ASP is sometimes defined as the one-to-many business model, leveraging

the infrastructure to service several clients from the same capital base (Swift

2001; Boyle 2002). While others contend that a one-to-one relationship does

not preclude an organisation from being seen as an ASP (Lavery 2001).

Differing definitions of the ASP would include services such as web-based

email (e.g. hotmail, yahoo); however other definitions would exclude

applications that are not available ‘off-the-shelf’ (Timbrell et al. 2001).

Summarising the literature, the term Application Service Provision refers to

the specific business model of leveraging investments in a single back-office

infrastructure (i.e. hardware, database and software) to deliver application

functionality over a network to multiple clients paying rental or other usage

based fees. The ASP is responsible for every part of the delivery up to the

client’s local network (and possibly including a customer-side thin client). It is

a form of outsourcing; however it differs from traditional outsourcing

arrangements in 5 significant facets summarised in Table 7 (adapted from

Yao and Murphy 2001).


QUT Page 60

Table 7: Traditional Outsourcing vs. ASP (Yaho and Murphy 2001)

A good example of the industry stratification is presented in Figure 16

(Seymour and Edwards 2001).

Figure 16: xSP Taxonomy (from Seymore and Edwards 2001)

Although the taxonomy presented specifically depicts only the ASP model of

delivery, it serves as a good basis for IT services as a whole. ASP is a

specific delivery method of IT Services; however the layers are still valid at a

generic level. Another layering of the ASP market presented in Figure 17,

also provides a basis for the layering of the IT services market as a whole

(Tao 2001).

Figure 17: Four layered stratification of the ASP market (from Tao 2001)

halla


halla


halla



QUT Page 61

2.7.2 Taxonomy of IT Services

ASP is a specific delivery method of IT services, it does however provide a

good overview of the layers needed to deliver IT services regardless of the

method. Generalised from the xSP taxonomy and from Tao’s 4 layers one

can derive an IT service stratification presented in Figure 18. Placed beside

each of the layers is each service defined in Figure 15 which defined the

separates components of IT services. The IT industry is an extremely

complex environment, and therefore any simple classification scheme should

be seen only as a heuristic.

Figure 18: Simplified Taxonomy of IT Services

IT services can be supplied by a single (usually large) organisation although

the supply chain is typically filled with niche players. For example, company

A could provide the technical infrastructure and hosting while company B is in

charge of technical maintenance and application of the system, and company

C provides database support and tuning while company D provides support

services to end-users, while company E manages the Information

Communication Technologies (ICT).

A brief discussion of the layers presented above is presented here for clarity.

Solution Delivery

Service Delivery

Infrastructure Management

Network Management

Consulting, Education, Business Processing Services

Software Support, Hardware support Configuration Management,

Capacity Management

Application Hosting, Data Centres, storage centres

Network Management


QUT Page 62

Network Management

In this case the network is the transportation networks which connect the IT

infrastructure to the local network of the end user, assuming they are

geographically separated. Hence, network management is the planning,

organising and control of this network. It involves tasks such as managing

negotiations with other network providers, ensuring quality of service at the

network layer, ensuring connectivity, managing network resources such as

cabling and switching stations. Network management is seen as a subset of

the activities provided by the Information and Communications Technology

Industry (ICT).


Infrastructure management is what some would describe as “looking after the

boxes”. Infrastructure in this case refers to the infrastructure from which the

IT services are being provided excluding the transportation networks. It

includes the internal network of the end user organisation and the network of

the infrastructure centre, the actual physical infrastructure for the housing of

the IT equipment, particularly the servers and hard-drives. The scope

includes providing services such as UPS, physical security, certain disaster

recovery mechanisms such as redundant or lights-out facilities. This layer

captures many of the processes associated with application hosting.

Service Delivery and Support

Service support involves dealing with problems in the IT environment. It is

largely re-active though it can have proactive elements. It involves activities

such as receiving incident reports from users or others, finding solutions to

these problems and implementing them in the production systems. Service

delivery is concerned with all the ongoing activities that ensure the continued

operation of the system for the end user. It includes activities such as

configuration management, capacity management and service level

management. This layer includes the administration of applications including

ERP’s.


QUT Page 63

Solution Provision

Solution provision is a wide catch-all for the ‘value-add’ or extra activities that

can be provided to supplement the IT services. Examples include wrapping

the underlying layers into a single package and providing a single face for the

customer, providing consultancy on which IT service provider and packages

to choose, or even business process re-engineering, business process

outsourcing or strategic IT guidance.

2.7.3 IT Services Lifecycle

IT Services also follow a relatively standard lifecycle. Presented here are

several lifecycle models that have been used to derive the IT services

lifecycle used in this thesis.

The Microsoft Operating Framework (MoF) documents best practices,

principles and models for operating an IT infrastructure. The MoF consists of

4 phases “Planning”, “Preparing”, “Building” and “Operating”.

CORBIT, described in more detail in 2.8.2, (Guldentops et al. 2000) contains

a high level lifecycle of IT services. The 4 major phases are “Planning and

Organisation”, “Acquisition and Implementation”, “Delivery and Support” and

“Monitoring”. The following definitions are quoted directly from the CORBIT

framework:

“Planning and Organisation

This domain covers strategy and tactics, and concerns the

identification of the way IT can best contribute to the achievement of

the business objectives. Furthermore, the realisation of the strategic

vision needs to be planned, communicated and managed for different

perspectives. Finally, a proper organisation as well as technological

infrastructure must be put in place.

Acquisition and Implementation

To realise the IT strategy, IT solutions need to be identified, developed

or acquired, as well as implemented and integrated into the business


QUT Page 64

process. In addition, changes in and maintenance of existing systems

are covered by this domain to make sure that the life cycle is

continued for these systems.

Delivery and Support

This domain is concerned with the actual delivery of required services,

which range from traditional operations over security and continuity

aspects to training. In order to deliver services, the necessary support

processes must be set up. This domain includes the actual processing

of data by application systems, often classified under application

controls.

Monitoring

All IT processes need to be regularly assessed over time for their

quality and compliance with control requirements. This domain thus

addresses management’s oversight of the organisation’s control

process and independent assurance provided by internal and external

audit or obtained from alternative sources.” (Guldentops et al. 2000)

p16.

The lifecycle model and terminology used in this thesis re-uses these

concepts and is presented in Figure 19. It defines the 4 phases of planning,

implementing, support and delivery and retirement.

Figure 19: IT Services Lifecycle

A brief description of each of the stages is presented next. This lifecycle

tracks the relationship between the provider and consumer, and it could have

several iterations particularly of the planning and implementing stages.

Plan

Implement

Support

Retire


QUT Page 65

Planning

This stage starts after an initial contact between the service provider and

consumer has been made. It involves the matching the needs of the

consumer with the provider’s services, and if necessary a degree of

customisation of the services on offer. Assuming the consumer is satisfied at

the end of this stage, the implementation or go-live can commence.

Implementation

This involves the roll-out of the service and any required changes.

Transitioning of any legacy systems, human or other legacy resources also

happens in this stage.

Delivery and Support

In this stage, the actual run-time value add service takes place. This phase is

concerned with providing and maintaining the agreed levels of service, in

order to enable the processes of the consumer.

Retirement

Should the services of the particular service provider no longer be required,

then the retirement is the phase that disengages the provider from the

consumer. This could include handing over data, cancelling legal obligations,

possible re-allocation of staff and eventually decommissioning the service.

Often the retirement of a service may be integrated with the planning of a

new service designed to support the same needs.

2.8 ITSP Business Reference Models

The previous section explored IT services and positioned the model in terms

of IT services market layer and lifecycle phase. As introduced in Chapter 1,

proven business process management techniques have not been applied to

the IT service provider domain.

This section is in two parts, firstly, a description of the reference model that

could help to apply the business process management techniques to the IT

service provider domain, then an examination of the current related models.


QUT Page 66

2.8.1 Desired IT Service Provider BP Reference Model

From the discussion in Chapter 1 and the linkages to BPM described in

Chapter 2 we can derive the requirements of a suitable reference model. It

would obviously describe the business processes of an IT service provider.

The model would cover the complete scope of the IT service provider

organisation but also contain a single, detailed and integrated model,

containing accepted “Best Practice” processes.

The model should be specifically for those that specialise in IT services, i.e.

the IT service provider organisations, the IT outsourcing vendors, be updated

as practices change, and to be used as a true template to save derivation

costs.

Modern BPM techniques require the use of semi-formal modelling languages,

to ensure the consistency of the model and the language used in the model

and to help the translation into IT based support solutions.


QUT Page 67
















Available through

membership



Table 8: Desired characteristics for IT Service Provider BP Reference Model

2.8.2 Existing Models related to IT Service Provision

This section looks at selected Business Process Reference Models for IT

service provision that have served as input to the proposed reference model.

A limitation of this section is the access to proprietary knowledge in the form

of IT Service Management (ITSM) reference models, specifically those held

by ITSM and related activities vendors, including consultancy companies and

IT Management software and services companies. This thesis excludes

those models to which the research team could not obtain access.


QUT Page 68

ITIL (Information Technology Infrastructure Library)

ITIL, which had its genesis in the 1980’s, is a publicly available best practice

definition of IT service processes originally produced by an arm of the UK

government. ITIL concentrates on IT service management (ITSM) and is a

living model. One of the major contributors to the continuing development is

an independent industry group, the IT Service Management Forum (ITSMf at

www.itsmf.com). Since its early introduction ITIL has been updated and

refined with input received via various channels and a large and active user

group particularly in Europe. ITIL is a widely accepted best practice model

and contains detailed process descriptions at a Task level. However, ITIL’s

scope is tightly focused on ITSM to the exclusion of other IT service provision

(ITSP) processes. For example, supplier interface, HR, CRM and other

processes are not covered in ITIL. Another limitation of the ITIL models is the

lack of top down structure. Possibly due to the fractured nature of the

creation of ITIL, it was developed originally as around 60 individual booklets

on isolated areas of IT, with different authors and perspectives, it is

frequently inconsistent and the processes are difficult to fit together and

consolidate.

An attempt to provide a high-level integration of the ITIL process models has

been produced by Enterprise Managed Services in the EMS Process

Reference Model (Enterprise Managed Services, Unknown) shown in Figure

20.


QUT Page 69

Figure 20: EMS’s High level ITIL process model

ITIL also lacks integration of its process elements as acknowledged by the

following quote from the ITIL documentation:

“The major elements of the ITIL books can be likened to overlapping jigsaw

puzzle pieces … , some of which have a precise fit, and some of which

overlap or do not fit together accurately.” (CCTA 2000 section 1.4).

ITIL is also inconsistent in presentation, as shown in Figure 21 which comes

from (left) Annex 5D and (right) chapter 6.6.

Business/Customers

IT - Business Alignment Service Support

New

Projects

Business

requirements

Service

Definition

CRM Service

Desk Incident

M’ment

Problem

M’ment

Release

M’ment

Config

M’ment

Change

M’ment

Cost

M’ment

Contigency

M’ment

Capacity

M’ment

Avail.

M’ment

SLM

Storage

M’ment

Desktop

M’ment

App. and

DB M’ment

Systems

M’ment

Network

M’ment

IT Environment

Service

Delivery

Infra.

M’ment


QUT Page 70

Figure 21: Examples of inconsistencies in modelling in ITIL documents

The classification table of ITIL is presented in Table 9.
















Available through

membership



Table 9: ITIL Classification


QUT Page 71

IT Service Management Capacity Maturity Model

The Information Technology Service Capacity Maturity Model (IT Service

CMM), is a result of several projects involving universities, private

organisations and government departments based mainly in Europe. The

model attempts to define what functions should be in place to reach a certain

level of maturity. It is a form of quality management because it provides the

what, but not the how, i.e. the functions but not the processes.

“The IT Service CMM only specifies what practices are needed, not how they

need to be implemented” (Niessink et al. 2002 p12)

Its objectives are two fold, to allow an assessment of the current state of an

organisations IT service provision as well as providing directions and steps

for improvement of the service provision. The model references ITIL as a

good source of the “how” these processes should be conducted.

Figure 22: IT Service CMM Methodology


QUT Page 72

The actual model is built using the methodology outlined in Figure 22. Along

with the definition of Key Process Areas for a particular maturity level, the

model defines the goals of each of these areas and also the common

features. The common features describe mostly organisational and policy

issues that commonly exist to support the process area.

Each common feature is then examined using a lifecycle-like model

(Commitment to Perform, Ability to Perform, Activities Performed,

Measurement and Analysis, and an overarching Verifying Implementation),

and key practices within each of these lifecycle steps is provided.

The high level view of the model showing the levels of maturity with the

associated processes is provided in Figure 23.

Figure 23: The IT Service CMM


QUT Page 73

The classification of the IT Service CMM is presented in Table 10.
















Available through

membership



Table 10: IT Service CMM Classification

MoF (Microsoft Operating Framework)

The MoF, developed by Microsoft, references several ITIL definitions in its

attempt to provide the technical guidance within the Microsoft “Enterprise

Services” (Microsoft Corporation 2001). The Enterprise Services outlines the

lifecycle in planning, preparing, building and operating lifecycle for Microsoft

technical solutions. The MOF acknowledges ITIL as the current industry best

practice for IT service management. The MOF only uses selected parts of

ITIL and offers no additional information in terms of ITSM or ITSP processes.

It is focused on technical issues. Also, in its attempt to model the lifecycle of

system implementation, its focus is not on providing ITSP processes.


QUT Page 74

Figure 24: Microsoft Operating Framework

The overview of the scope of MoF is presented in Figure 24. The

classification is presented below.


QUT Page 75
















Available through

membership



Table 11: IT Service CMM Classification

Garschhammer et al.

Garschhammer et al.’s work on building a service provider model

acknowledges the increasing importance of the supply chain in service

provision (Garschhammer et al. 2001). Using a top-down methodology

Garschhammer et al. have produced a generic service model that defines

commonly needed service related terms, concepts and structuring rules.

Garschhammer et al.’s top-down modelling approach creates the opportunity

to capture all SP processes. It is however, lacking finer granularity and fails

to provide a structure for further refinement into process models.


QUT Page 76

Figure 25: Garschhammer et al. Service Model

The classification is presented below.

Table 12: Garschhammer et al. Classification

halla


halla



QUT Page 77

TOM (Telecom Operations Map)

The TOM was developed to define the business process for the Information

and Communication Services Industries. Introduced in 1995 under a different

name, the TOM was developed by the TeleManagement Forum. It provides

guidance on systems delivery, system management and billing. TOM

focused exclusively on the processes directly related to service provision, to

the exclusion of supporting processes. TOM has since been superseded by

eTOM (see below).

eTOM (expanded Telecom Operations Map)

eTOM is an extension of the TOM and provides a business process

framework for service providers (TeleManagement Forum 2001). eTOM

provides a top down hierarchical structure into which processes, or at least

functions, can be classified. As well as providing this framework, eTOM gives

an indication of the interactions and dependencies of these functions on one.

Although eTOM is aimed at the Information and Communication Services

industry at higher levels, the generality of the model makes it applicable for

other service providers in the IT and related industries. This model attempts

to show the interrelations between identified processes, but is sometimes

confused between linking events and data dependencies. This lack of

consistent sequential and temporal order of activities makes eTOM less of a

process model and more of a classification framework for processes or

functions with some interrelationships between the processes shown at the

lower levels.

Figure 26 shows the highest level of the eTOM model (Anonymous 2001

p.20).


QUT Page 78

Figure 26: eTOM Business Process Framework - Level 0 Processes

eTOM’s classification is presented below.


QUT Page 79
















Available through

membership



Table 13: eTOM v2.5 Classification

CORBIT

Control Objectives for Information and related Technology (CORBIT) is

positioned as a model for IT Governance, which it defines as

“A structure of relationships and processes to direct and control the

enterprise in order to achieve the enterprise’s goals by adding value

while balancing risk versus return over IT and its processes.”

(Guldentops et al. 2000 p.5)

It is aimed at providing the monitoring guidance to ensure that business

needs are met by IT operations and conforms to seven principles (e.g.

effectiveness, availability). In effect it is a large IT management performance

checklist, providing information on what aspects of performance to measure


QUT Page 80

and recommendations on how to measure them. It also provides a high-level

breakdown of the functions involved with the four defined lifecycle steps of IT

services (see section 2.7.3 for a discussion of the 4 lifecycle steps).

Figure 27: Corbit Overview

The overview of the CORBIT documents is presented in Figure 27. Although

Corbit provides a good basis for the control and auditing of IT management it

is not a process model. Its classification is presented below.


QUT Page 81
















Available through

membership



Table 14: CORBIT classification

2.8.3 Perceived Shortfalls in existing ITSP BPRM

IT service provision is a complex task, involving detailed technical issues,

people and management issues, organisational issues, frequent changes

and a high degree of customer interaction. It is also highly dependent on the

context of the process. Factors affecting the IT service provision include the

types of services provided, the relationship between the service provider and

customer or the size of either organisation along with many others.

Hence any attempt to provide a business process model for this domain is a

complex undertaking. The high degree of interaction and dependencies of

the processes in an IT service provision scenario also make the task of

mapping them highly complex. A model of such a situation needs to be


QUT Page 82

detailed enough so it is helpful in a practical setting, and yet abstract enough

so that at a higher conceptual level the interactions and dependencies can be

easily understood. The consistent and integrated linking of the higher-levels

with the lower levels is also extremely important, because one relies on the

other. The higher-levels depend on the lower-levels for the detail to make the

model useful and the lower-levels depend on the higher to provide a

conceptual entry point for the model, and to facilitate communication about

the domain. Most of the models lack this detailed level of descriptions and

are often only functional representations, not true process definitions.

ITIL contains the most detailed process information (it is the only one rated in

the Task level of detail other than the MoF which references ITIL heavily) and

its popularity in industry (Morin 1999; Duffy 2001; Dubie 2002; Kara 2002)

could partly be attributed to this level of detail, which gives managers and

operators tangible grass-roots ideas and suggestions. The other models are

higher level and lack this detail needed to make a difference at the

operational and implementation level.

ITIL lacks this higher level. It contains inconsistencies in content and format

and is very hard to conceptualise at the higher levels. Taken in isolation, the

advice it offers is useful, but stepping back from this detailed view and trying

to fit the pieces of information together is a difficult task. ITIL is also not

supported in a modelling tool and, although it claims to be applicable in the

commercial IT service provider domain, it is not specific to this environment,

and indeed is more focused on in-house service provision.

It is the aim of this research to fill this gap by taking parts of the content and

structure of these models to provide a reference model that clearly shows the

higher level dependencies and interactions while at the same time providing

clearly defined and detailed guidance on the business processes at the Task

level for IT service provision.

2.9 Chapter Summary

This chapter has provided a review of the literature on reference models from

which a classification scheme for reference models has been derived. It


QUT Page 83

reviewed reference models related to IT Service Provision and presented a

brief discussion of IT service provision. From this discussion an IT services

market layering and lifecycle was derived. As a culmination of the literature

review the perceived weaknesses of the currently available business process

reference models for IT service provision have been identified. ITIL is the

only identified source that contains detailed advice about IT Service provision

at the Task level. The major weakness of ITIL however is its lack of top down

integration and consistency. The next section describes the research

methodologies applied to reach the stated goal of a reference model for IT

service provision.


QUT Page 84

Chapter 3: Research Design and Method

3.1 Introduction

The main goal for this research is to produce a partially completed reference

model for IT service provision. This goal produces several research

questions as outlined in Chapter 1. Due to the lack of work in the area of

reference models, their characteristics, development and use methods,

exploratory research methods are required to examine the identify the

concepts in the field. This chapter outlines the research design and

methodologies embedded in the design, which were employed to accomplish

the research goal and answer the research questions.

Firstly, the Research Design is presented, followed by sections on the Focus

Group research methodology and secondly the case study research

methodology. This chapter describes the research methods in a general

sense and provides justification for their use in this particular research

program. The specifics of the research methodologies as they are applied in

this research are presented later in the thesis, before the results of the

research stages are presented. This is done to allow the reader to examine

the results of the research stage with respect to its individual setting.

3.2 Research Design

Keeping the research goal in mind, that is the design of a reference model,

the research was designed in 3 major stages. The first stage, involved a

comprehensive literature review the results of which have been presented in

Chapter 2. The aim of this stage was to provide a basic understanding of the

domain of IT services and the concept of reference models. The second

phase of the research was the design of the models. It involved several focus

groups to validate and modify the models put forward by the author. The

outputs from this design phase were to be tested in case studies and the

opinions of those using the reference model examined.

During the literature review it became apparent that there was no literature

describing what aspects were important or desirable in a business process

reference model. This prompted research into the quality of business process


QUT Page 85

reference models using the case study methodology which is presented in

Chapter 4. The experiences and early results gained through the case study

on model quality significantly influenced the reference model design.

Another deficiency in the literature was a description of how reference

models should be designed; the literature review did not reveal any detailed

guidance on how to design reference models. The very few articles that

involved the development of a reference model did not describe in any detail

the steps that were used in the design, or comment on how future reference

models should be designed. The design procedure used for this research is

presented in Chapter 5. The actual design and validation of the model are

described in Chapter 6 and the testing of the model in Chapter 7.

Figure 28: Research Design and embedded Methodologies

Each of the research methodologies used in this research are now described

in a general manner and their use justified. The specifics of the uses of the

methodologies, e.g. focus group, data collection and analysis, are presented

in the relevant sections of the thesis.

Literature Review

RM Quality Case study

protocol

Draft Model

BP RM Quality Attributes

Case Studies

Focus Groups

Validated Model

Case Studies

Tested Model


QUT Page 86

3.3 Focus Group

3.3.1 Introduction

Focus groups were first used during the second world war, when government

officials desired to assess the effectiveness of their propaganda and soon

moved to explore the effect of films and television (Merton R 1956). Their

application has been extended to marketing and corporate image campaigns.

3.3.2 Characteristics

The focus group is an effective method for gathering the general opinion of a

target audience by providing an environment that allows probing for

clarification and justification of opinion (Morgan 1988 in Saulnier 2000a),

capture of peoples’ reactions to others comments (Saulnier 2000b), a degree

of spontaneity (Magill 1993 in Saulnier 2000a) and a degree of completeness

(Kruger 1994 in Saulnier 2000a).

Research into areas that have not been sufficiently explored require initial

exploratory work (Sofaer et al. 2001). Morgan (1988) suggests that focus

groups are a suitable research method for orienting a researcher to a new

field.

Morgan states that the "hallmark of focus groups is the explicit use of the

group interaction to produce data and insights that would be less accessible

without the interaction found in a group" (Morgan 1988 p.12).

3.3.3 Conducting Focus Groups

Focus groups consist of a ‘round-table’ meeting with researchers and

industry peers for the discussion of a precisely defined topic under strict

moderation. Focus groups generally have between 6 and 10 participants.

There are many examples of larger groups (Saulnier 2000b), although larger

groups are more difficult to manage and tend to allow some participants to

say nothing or follow the more dominant personalities (O'Neill et al. 1999).

Focus groups are typically 1 to 2 hours in length and involve three facilitators;

the moderator, note taker and time keeper (O'Neill et al. 1999).


QUT Page 87

3.3.4 Justification

There were three reasons focus groups were used for the design of

reference models; the first historical, the second theoretical and the third

practical.

Firstly, from a historical perspective, existing reference models were largely

designed from group collaborations. For example, eTOM (version 2.5) has

listed amongst its authors some 49 individuals and over 30 organisations. It

is reasonable to conclude that the quality and acceptance of a reference

model depends, to some extent, on the number and quality of the participants

involved in the design process. Given such a participant pool the next

consideration is how to consolidate opinions to into the reference model. A

focus group as discussed above provides an opportunity to reflect and

compare on the opinions of others and as such is appears a suitable method

for the design of a reference model.

Secondly, from a theoretical perspective, the use of group discussions has a

backing for use in developing generalisable models as described by Frank

(Frank 1999). He argues that the only way to overcome subjective

perspectives while creating reference models is “the idea of a rational

discourse”. He goes on to argue that participants in this discourse should

constitute those that have “sufficient knowledge” about the subject, and that

ideally this should include everybody who is “directly affected by the artefact

under consideration”. For the purposes of this research the input from

everyone affected was impractical. Taking into account the need for a

consolidated view of the IT service provision domain, the focus group method

was chosen with representatives from large IT service providers (for further

details about recruitment see Chapter 3).

The third reason that focus groups were chosen for the model design was

that process modelling is usually done with modellers and several domain

experts (McGowan and Bohner 1993), effectively a small focus group. No

literature exists on how to create a reference model, so techniques have

been borrowed from the process modelling domain.


QUT Page 88

3.4 Case Study

3.4.1 Introduction

The most commonly cited work describing the case study methodology is

Yin’s book “Case Study Research” (Yin 1994). Commonly cited works in the

Information Systems field include Benbasat et al. (1987) and Lee (1989).

The term case has been used in several contexts. It has been used to

describe a unit of analysis or to describe a research method (Myers 1997). It

is used in this thesis as the research method.

Myers (1997) quotes Orlikowski and Baroudi (1991) and Alavi and Carlson

(1992) as saying that case studies are the most commonly used qualitative

methods in information systems research.

Historically, case studies have been seen as an unscientific research

method, despite having been used in a variety of research areas including

social research, history and economics. Their widespread use, however is an

indication that this historical reluctance to accept this research method is

diminishing.

3.4.2 Characteristics

“The case study method refers to a group of methods which emphasize

qualitative analysis” (Gable 1991 p 3.1). It is defined as an “Empirical inquiry

that investigates a contemporary phenomenon within its real-life context” (Yin

1994 p.13) and can be conducted for exploratory, explanatory or descriptive

purposes (Yin 1994; Tellis 1997). Case studies are applied to serve an

exploratory function in this research to investigate a contemporary

phenomenon within its real-life context.

Yin (1994) recommends the use of multiple case studies, when the intent of

the researcher is to build and test a theory (Gable 1994; Yin 1994). Yin

suggests that a single case study is a relevant approach to discovering new

or un-researched material in a natural setting (Yin 1994).


QUT Page 89

Benbasat, Goldstein and Mead (1987) add that case study “is an appropriate

way to research a previously little-studied area” (Benbasat et al. 1987).

According to Yin, there are at least 5 applications for case studies. They are;

to explain the effect of some intervention, to describe an intervention itself, to

illustrate certain topics, exploration of the effects of an intervention when the

outcomes of the intervention may not be clear, and in the meta-evaluation

(Yin 1994 p.15).

They are used in this research to illustrate certain topics, namely the user

perceived quality attributes of reference models, and to explore the effects of

an intervention, when presenting the developed reference model for use in

BPM projects and examining the perceived impact.

3.4.3 Conducting Case Studies

A comprehensive case study protocol should be derived to direct the case

studies by carefully documenting all procedures relating to the data collection

and analysis phases of the study. The protocol defines the structure of the

overall case study effort and is specially advantageous for exploratory

studies as this, for (1) they force the researcher to consider in advance, the

objectives and goals of the study, (2) to help avoid redundant effort, and any

potential omissions of the data collection and finally (3) to support the

communication and documentation efforts (Gable 1991; Yin 1994).

The sampling frame, (defining the contextual elements such as who to

contact, where to contact, how to contact etc.) should be derived based on

past theories and the study objectives. Qualitative data collection mechanism

such as in-depth interviews, observations, and content analysis of existing

documentation were conducted to collect ‘rich’ information about the

application of reference models within different contexts. All relevant data

should be maintained in a ‘case database’ (Miles and Huberman 1984; Yin

1994) and close linkage between the data, evidence and the research goals

must be maintained throughout the analysis.


QUT Page 90

3.4.4 Justification

Case studies have been chosen as the research method for three reasons.

Firstly, the practical research into model quality and especially reference

model quality is extremely limited. Hence using an exploratory method, such

as case study, is appropriate. As shown in Figure 28, which describes the

research design, the case study method has been used twice. The first,

exploring the quality of reference models, is of Yin’s illustrative type. The

second, the examination of the use of the developed reference models,

explains the effects of the use of the reference models.

The case study offers an opportunity to observe real life behaviour and

provides a natural context, with all the pressures and interferences that that

entails. This was important for the research team, as this research is aimed

at the examining the use of reference models and their quality from the

perspective of those using them and as such should consider real life

constrains and impacts.

Thirdly, the feasibility of the case study method made it an attractive

opportunity. The research team was fortunate to have close access to

several organisations which were experienced in the area and which were

willing to provide their thoughts and time to this research.

3.5 Chapter Summary

This chapter has described the research methods used in this research and

provided justification for their selection for use as well as outlining the way to

conduct research using these methods. Further discussion of the specifics of

the research methods, e.g. participant selection is discussed before the

presentation of the results of the research.


QUT Page 91

Chapter 4: Reference Model Quality 4

4.1 Introduction

During the review of the literature, very few publications were found

discussing exactly what a reference model should look like and contain. To

provide guidance and understanding for the development of the reference

model produced in this research, work was conducted to examine what were

the quality aspects of business process reference models, and what should

be included to supplement these models. Figure 29 shows how this chapter

fits in relation to the reference model lifecycle.

Figure 29: Chapter 4 in relation to the Reference Model Lifecycle

The research team wanted the derivation of the quality aspects of reference

models to be based on real life experiences, not only theoretical constructs,

and hence case studies were conducted.

This chapter details these case studies, their motivation, the terminology

used throughout the work, the design, data collection, analysis, results and

conclusions.

4 Parts of this chapter is published in the proceedings of the Australian Conference on Information Systems conference in Perth, November 2003 in the paper Taylor and Sedera “Defining the Quality Attributes of Business Process Reference Material”.

Design Reference

Model

Reference

Model

Use Reference

Model


Quality Attributes


QUT Page 92

4.1.1 Motivation

The motivation behind this study was to understand what defined reference

model quality in order to incorporate those aspects which were important to

quality into the reference model.

4.2 Terminology

To clarify the discussion this section introduces the terminology used to

describe quality in this paper.

A brief review of the marketplace for reference models suggests that

producers, particularly commercial producers, are offering not only the

reference model but also a range of other services and products related to

the reference model (e.g. training, case studies, feedback mechanisms)

which is termed model support. The overall package offered by the producer,

i.e. the model and the model support, is termed the reference material. Of

course the major part of the reference material is the reference model and

hence is the focus of our research.

The Quality Framework includes the Quality Dimensions, which are high level

constructs or the goals of quality. The quality dimensions are at a conceptual

level and serve as a categorisation for the quality attributes. Quality attributes

are the sub constructs of the dimensions. They are the practical means of

achieving these high level quality dimensions as described in Figure 30. They

can also be seen as the ends, because achieving these attributes

theoretically directly contributes to the quality dimension.

Figure 30: Quality Terminology

Quality Dimension 1

Quality Dimension 2

Quality Dimension X

Dimensions

Quality Attribute A

Quality Attribute B

Quality Attribute C

Quality Attribute D

Quality Attribute E

Attributes


QUT Page 93

This simply provides use the terminology that is used throughout the rest of

the discussion.

4.3 Research Question

The research question driving this sub-study is:

What is quality in terms of business process reference material?

Quality needs to be defined from a particular perspective which is made up of

the view of a particular class of observers and the purpose of the use. Figure

31 shows the relationship between view, purpose, perspective and quality.

The figure indicates that a perspective is made up of a particular purpose and

a particular view, and that from each perspective the perception of quality

may differ. The important fact that this outlines is that changing perspective

(i.e. by changing the view, or purpose, or both) with which an entity is viewed

will change the perceptions of quality about that entity.

Figure 31: Relationships between view, purpose, perspective and quality

The perspective examined in this chapter is from those who are using the

model for business process re-engineering. Therefore, the view is that of the

users (i.e. those directly applying the model). Although the user view is only

one type of perspective which is needed to define quality, it is believed that

this view is an important one, as the users of the model are effectively the

customers of the reference model producers. This view is of those who are

Perception of Quality

Perspective

determines

View (user)

Purpose (bpm)

Is part of Is part of


QUT Page 94

involved with the application of the reference model, i.e. those responsible for

the “Use” phase of the reference model lifecycle, as shown in Figure 32.

Figure 32: RM Lifecycle phase in which the Quality research is based

The purpose of the reference models selected by the organisations involved

with this research is to aid in business process modelling, and these models

were used for this purpose.

In this research quality is defined as:

The degree of existence of user desired attributes.

This definition is consistent with other definitions of quality which have been

collected and summarised by Ivancevich et al. (1997 p.10).

4.4 Research Design

First, a comprehensive review of the relevant literature was conducted

drawing upon related fields namely reference models, conceptual model

quality and business process modelling. From this the quality framework was

derived. This framework provided the basis from which to draw questions

about specific attributes of quality. User perceptions and reactions to the

proposed quality attributes were then tested within two case studies where

business process reference models were extensively used.

Design Reference

Model

Reference

Model

Use Reference

Model


Quality Attributes


QUT Page 95

The primary objective of the case studies was to identify those attributes that

were perceived by the users as important for reference model quality.

4.5 Quality Framework

Several existing popular quality frameworks are presented here as a basis for

the derivation of the quality framework used in this research.

4.5.1 Quality of Modelling Framework

Lindland, Sindre and Solvberg (1994) published a paper outlining a

refinement of quality aspects of a conceptual model. The work was heavily

influenced by the then popular data models. They helped to separate the

sometimes jumbled concepts of the definitions of quality and provided a

simple framework for the three types of quality. They defined four important

entities with relation to the quality of a model.

The first, the model itself, contains a number of statements. Second, the

audience interpretation is the set of interpretations that the audience has

made based on the model. The third entity is the domain, which consists of

all possible statements that are correct and relevant to a particular problem.

Lastly, the language is all the possible statements that would be possible

given a particular set of language rules (i.e. the syntax).

The quality of the model is derived from the relationship between these

entities. The qualities defined are syntactic, semantic and pragmatic quality.

Syntactic quality is the correspondence of the model with its language, in

simple terms “the more closely the model adheres to the language rules, the

higher the syntactic quality” (Lindland et al. 1994 p46).

Semantic quality is the correspondence of the model with its language. They

defined two types of semantic quality, firstly validity, which suggests that all

the statements in the model are correct and relevant to the problem.

Secondly, completeness means that the model contains all the statements

about the domain.


QUT Page 96

The pragmatic quality is the correspondence of the model to the audience.

Pragmatics is concerned with alternative ways of expressing the same

semantics. The goal for pragmatic quality is comprehension, when all the

model statements have been interpreted correctly by their relevant audience.

The Quality of Modelling (QoM) was also extended by Krogstie et al. (1995),

to include Physical model, which is the degree of persistence and availability

of the statements, Language quality, how well the language suits the domain,

Social quality, which is how well the audience agrees about the model.

4.5.2 Guidelines of Modelling

Becker, Rosemann and Uthmann (Becker et al. 2000) put forward their

guidelines of business process modelling outlining 6 quality factors of

business processes models. In their work on extending the definition of

quality beyond data modelling and focusing on business process model their

goal was to extend the concept of model quality beyond the notion of

syntactic correctness. The factors were correctness (of semantics and

syntax), relevance, economic efficiency, clarity, comparability and systematic

design.

4.5.3 Semiotic Framework

The semiotic framework (Stamper 1992; Falkenberg et al. 1998) is not a

quality framework as such. It is a 6 layer model that describes

communication. It provides a good model for understanding the various

levels of communication and how they interact. It is discussed here because

it provides a broad scope of communication and may suggest qualities that

may not have been already covered by the two quality frameworks. The 6

layers are the physical, empirical, syntactic, semantic, pragmatic and social.

4.5.4 Deriving the Quality Framework

The framework and dimensions are derived to provide a theoretical basis and

to ensure that all previously mentioned aspects of quality have been included

in the case study questions. They served as categories in which the


QUT Page 97

assimilation of the quality attributes defined by various authors could be

performed.

The overlap between the three frameworks and the derived framework is

presented in Table 15. The first column defines the new proposed terms, the

second, the Quality of Modelling (QoM) combines the qualities defined in the

Lindland et al. and the Krogstie et al. papers. The Guidelines of Modelling

(GoM) summaries the guildlines proposed by Becker et al. and finally the

semiotic framework summaries the aspects of communication.

Proposed Terms

QoM (1994 + 1995) GoM Semiotic

Framework

Syntactic Correctness Syntactic

Comparability

Systematic design Syntactic Quality

Language Quality

Semantic Correctness Semantics Semantic Quality

Relevance

Pragmatic Clarity Pragmatics

Physical Quality Physical

Empirics

Pragmatic Quality

Social Social Table 15: Overlap in the Modelling frameworks and proposed quality dimensions

The proposed quality dimensions have been made by interpreting the

frameworks and grouping the similar concepts. For example, Lindland et al.

(1994) and Becker et al. (2000) both identify that having semantic

correctness is an important quality aspect of a model and a business process

model respectively. This also maps onto the semiotic framework’s

“semantics”.

We define 3 dimensions of quality for reference models; Syntactic, Semantic

and Pragmatic as shown in Figure 33. Although this seems to be a direct

replication of the Lindland et al. framework, the definitions of the quality

dimensions is expanded from the original to include influences from the

Guidelines of Business Process Modelling (Becker et al. 2000), Semiotic


QUT Page 98

framework and the revisions to Lindland et al.’s original work in (Krogstie et

al. 1995) and other papers. The new definitions are discussed next.

Figure 33: Quality Framework for this paper

Syntactic Quality

The languages used in business process reference models are often not

languages with strict, formally defined rules. Therefore there is no formal test

for compliance or non-compliance with a set of language rules is possible.

Rather, the syntactic correctness relates to the properties that describe the

structure and organisation of the model itself as in Misic and Zhao (2000).

Often reference models do not have a defined meta-model or accompanying

modelling conventions, hence judgements must be made about the implied

meta-model and conventions. By defining syntactic quality as such, we are in

effect broadening the definition of language to include not only the implied

meta-model but also the implied layout, overall design and underlying

concepts that have been applied to depict the content of a model.

Using this definition of language, we see that syntactic quality is not only the

strict applications of the grammar and symbols, but also how these are used

in terms of consistency, especially with respect to aspects such as layout,

naming conventions etc. It also includes the mapping of the language and

constructs used to depict the real world entities as can be explained in

glossaries or ontologies for example. This definition of syntactic quality

covers Becker et al.’s (2000) “(Syntactic) Correctness”, “Comparability” and

parts of the “Systematic design”. Our definition maps to the semiotic

framework’s “syntactic” layer.

Language

Audience

Domain Model Syntactic Semantic

Pragmatic


QUT Page 99

Semantic Quality

Semantic quality reflects how well the model captures what it is supposed to

capture as defined by the model scope statement or implied scope

statement. An ideal fit in this case is that the model correctly captures

everything of relevance and nothing of irrelevance. This is essentially

Lindland’s et al. (1994) original definition of “completeness”. This quality

dimension is similar to Becker et al.’s (2000) “(Semantic) Correctness”, and

“Relevance”. Our definition also subsumes Zamperoni and Lohr-Richter’s

“consistency” where no model statement contradicts another model

statement (Zamperoni and Lohr-Richter 1993). This is the situation where,

although the language has been applied correctly, two statements in the

model are contradictory. If two statements are contradictory then at least one

of the statements must be incorrect, hence we have classified this as a

semantic error. Semantic consistency is also mentioned as important in

semantic quality in Misic & Zhao (2000). Our semantic quality maps to the

semantic layer of the semiotic framework.

Pragmatic Quality

Again expanding from Lindland et al.’s (1994) definition, pragmatic quality is

defined here as how well the model is understood, which includes the quality

of the model itself and the quality of the support material e.g. training,

explanations etc. “Perfect” pragmatic quality would mean that every part of

the model is correctly interpreted by the relevant audience and that this

interpretation provides value to the audience. This quality dimension also

corresponds to Becker et al.’s “Clarity”. As a means to this understanding,

the distribution of the model is also important; hence pragmatic quality also

includes attributes of the semiotic framework’s physical layer. Our reasoning

being that an audience cannot interpret that which it cannot access. It also

includes attributes from social quality from Krogstie, Lindland and Sindre

(Krogstie et al. 1995) and the semiotic framework. Social quality was

included in the pragmatic quality because, assuming the model has only on

correct interpretation, any inconsistencies in individuals interpretations, which

is a lack of Lindland et al.’s social quality, must be due to at least one

incorrect interpretation. This incorrect interpretation is therefore an


QUT Page 100

expression of poor pragmatic quality of the model; hence social quality is

dependent on pragmatic quality and is included within it for this discussion.

Feasibility

One aspect that was left out of our framework that has been repeatedly

mentioned in literature is the concept of “feasibility” (Lindland et al. 1994) or

“economic efficiency” (Becker et al., 2000). This type of quality weighs the

cost/benefit of further improvements, and asks the question “does the cost of

incrementally improving the model out-weigh the benefits gained from such

an improvement?”. At the point the cost is higher, the literature suggests that

the optimum economy efficiency has been achieved. This concept is solely

focused on the design of a model. From the user requirements point of view,

the reference model producer’s effort is irrelevant and probably unknown and

as such we excluded it from the case study framework.

Framework Summary

The quality framework is the theoretical basis we have developed to ensure

that we ask the right types of questions about previously mentioned quality

dimensions and attributes and to provide a high level view for the data

analysis. The major outcome of this research is the list of specific quality

attributes identified from the case studies.

4.6 Case Study Descriptions

The reported study was conducted in two organisations: Queensland Rail

(QR) and Telstra – Australia. Contained here is the context of the usage of

the reference models within these organisations. For a brief description of

these organisations see the Appendix E.

These organisations were involved in the research because they undertook

process modelling activities using business process reference models, and

were accessible to the research team.

Today, modelling is extensively used at QR within different projects and for

multiple purposes. The Supply Chain Operations Reference Model (SCOR)

(Anonymous 2002) was extensively applied within one of QR’s process


QUT Page 101

improvement research projects; the Rail supply chain optimisation project.

The Rail supply chain optimisation project was proposed as a strategic

initiative to develop a methodology that QR managers can use when deciding

how to manage and improve the performance of their inbound supply chains.

Supply chains require all parties to move in unison. Process modelling came

into being within this project to address this need – to have a standardised

way to exchange information, within a wide variety of stakeholders of a

supply chain.

Telstra is heavily involved with the development of eTOM and is working on

using the framework to develop standards both within the company and in its

interactions with others. Telstra’s adapted version of eTOM, is named

TeTOM. Telstra uses TeTOM for several purposes, including the modelling of

the internal processes and as a method of identifying duplication of

processes, or resources to support these processes. Telstra is also looking at

using the reference model for process improvement projects.

4.7 Data Collection

A comprehensive case study protocol was derived (see Appendix A),

documenting all procedures relating to the data collection and analysis

phases of the study.

Data was collected from 5 respondents (2 from Telstra and 3 from QR) from

the case sites in the form of semi-structured interviews. All interviewees had

extensive experience in using business process reference models. The

questions were drawn from the literature using the framework discussed in

the first part of this chapter. General questions about the identified quality

dimensions were followed by a series of questions testing the individual

attributes of quality. After the interviewees had responded to each question,

they were prompted to comment on the importance of these attributes based

on their experience. Other sources (e.g. project documentation) were not

studied.


QUT Page 102

4.8 Data Analysis

Analysing case study evidence has been a noted challenge by most case

study experts (Yin, 1994, p.102). Only a few case data analysis techniques

and supplementary tools and techniques for data analysis have been

discussed in literature (Miles and Huberman 1984; Yin 1994). We first briefly

discuss the method we applied to analyse the case data. The next section

presents the findings with evidence.

“Codes are tags or labels for assigning units of meaning to the descriptive or

inferential information compiled during a study” (Miles and Huberman 1984 p.

55). A comprehensive data analysis tool; Nvivo 2.0 was used for the data

analysis of this study. Data were coded within the tool to elicit meaning and

present summaries of the phenomena investigated. A tree like node structure

was initially created to capture the quality factors of the a priori model;

namely Syntactic, Semantic and Pragmatic quality. Whenever a quality

attribute was mentioned or hinted at, it was coded with the relevant

node(s).The data coded under each code was re-analysed to make sure that

they did belong to the coded quality construct. The next phase re-analysed

the data coded under each node and recoded them at a further level,

differentiating between instances that discussed the weak or strong existence

of the quality factor and potential means of achieving the quality factor. In the

final phase of data coding, In-vivo (coding bottom-up, by using the key words

from the data) coding was conducted to derive a list of sub constructs that

described each quality attribute.

The codings were conducted by one coder (Sedera), and then verified and

modified after discussion by the interviewer (Taylor).

4.9 Findings

The main purpose of this research was to simply identify the quality

attributes, not to provide a relative ranking. Some indication to the relative

importance of the quality attributes can be obtained by comparing the

number of citations for each individual quality attribute across the different

case studies. ‘Numbers’ usually get ignored in qualitative research; however


QUT Page 103

a lot of counting actually does take place in qualitative studies when

judgements are made. For example, we “identify themes or patterns that

happened a number of times and that consistently happens a specific way”

(Miles and Huberman 1984 p.215). Thus, Table 16 presents not only the

different attributes for each quality dimension, but also the number of times

that they were mentioned as important across the case studies. This can aid

the interpretation of this study and provide a preliminary impression of the

relative importance.

Also of importance is the context with which the attributes were discussed. In

this section we interpret the Table 16 and also elaborate on the context,

presenting an accurate description of the case study findings. The results of

the case studies have been combined in the table, because responses were

generally uniform and we did not attempt any cross case analysis.

Syntactic Quality Semantic Quality Pragmatic Quality

Attributes cit. Attributes cit. Attributes cit.

Language must be clearly defined 14

Clearly define the scope of the model and its

limitations 10 Application Documentation 14

Language must be used consistently 14 Prior validate the models 5

Model users must be educated about the

reference model 10

The language must be simple to understand

7 Obtain feedback from stakeholders 5 Provide tool support 6

Have a glossary to define the key terms 7 Models must be

semantically consistent 4 User should be able to

maintain contacts with the vendors for clarifications

6

Provide Vendor training; explaining

the terminology 5 Avoid unnecessary

repetitions 4 The model must be easily accessible 3

All levels of the reference model must be defined

adequately

3 Try to capture the entire domain as a whole 4

Provide supplementary material to support user

understanding of the content 3

Create a meta model 3

Have realistic and feasible content (I.e. recommendations)

1 Model should be tailor-able to specific needs 2

Avoid the use of unfamiliar terms 2 Only have relevant

statements 1 Conduct vendor training on

the conceptual aspects of the model

1

Models must be laid out properly 2

Table 16: Citations of Quality attributes from case study interviews

Repeatedly mentioned was the need for a clearly defined and consistently

applied language. This point was raised often, and sometimes in response to


QUT Page 104

questions not dealing with the language. Interviewees consistently expressed

strong opinions on the importance of consistent clear language, e.g.

“extremely important”. In the words of one respondent the lack of consistency

“discredits the … quality” of the model. Respondents mentioned the

importance of the consistency of language use fits neatly with the emphasis

placed on consistency in the literature.

All the respondents indicated that the ability to ask questions and receive

answers was an essential part of using a reference model. These question

and answer sessions, delivered in a training situation or a simple email

conversation, were variously described as “very important” and “extremely

important” and saved users “a tremendous amount of time”.

A deviation from literature is found on the issue of relevance. Most existing

model quality frameworks indicate that a model is of low quality if it contains

irrelevant material. The results from the case studies indicate that having

material that is not relevant to the audience may not negatively impact on the

model’s perceived quality (i.e. only having relevant statements was

mentioned once, while capturing the whole domain was mentioned 4 times).

Most respondents indicated that at least part of the models they were using

were not applicable to their situation. However, this was not identified as a

quality problem. This may be an important distinguishing feature between

quality of specific models and reference models. It is a conclusion of this

research that a reference model has different requirements in terms of

completeness.

Again the issue of clarity in the definition and use of the model language,

especially process naming, is essential in this case to identify irrelevant parts

of the model, evidenced by comments such as “having the definitions for the

bits that weren’t relevant to us was essential”.

A model that is “overly-complete”, that is, it covers a domain that is beyond

the scope of a particular project or particular audience would require only

red-lining, i.e. deleting the non-necessary pieces (as compared to the other

methods of derivation, configuration and embellishment), while a reference


QUT Page 105

model that was not sufficiently complete, would require the addition of

sections of the model. Deleting parts of the model is much easier than

adding. Also, red-lining maintains the original syntactic and semantic

consistency of the model, because no mistakes are introduced to the model

in contrast with when the model users add new parts.

Another potential reason a reference model is of higher quality if it is overly

complete is the scalability of the model, meaning at later times more of the

model can be utilised, although this was not specifically discussed by the

respondents.

Linked to this issue of completeness was the result that users desired a

reference model to capture an entire domain, in one case an entire

telecommunications service provider as a commercial entity and in the other

a complete supply chain. A reason for this could be that a reference model

provides standardised terminology in what can be large and complex

domains, as is the case in these case studies. Sacrificing conciseness for

completeness may have a positive effect on user perceptions of the quality of

the model, by ensuring that the complete large and complex domain has

been mapped in its entirety, even if it is not used in such a widely scoped

modelling project.

One interesting concept that was canvassed in the interviews was the use of

pragmatic variation (or individualisation) in the models. That is, the idea that

the same underlying model would be presented to different stakeholder

groups, but with the terminology changed to suit the intended audience. This

strategy was raised during the case studies and is an important new concept

that could increase the pragmatic quality of a reference model.

A terminology matching dictionary or functionality could be developed by

reference model providers for various expected audiences, especially to use

terminology that is common in other reference models or for different

perspectives. This could be as simple as a table listing the terminology

matches between the model, other common models or common terms for

various stakeholder groups, e.g. technicians, managers etc. An interesting


QUT Page 106

example from the QR case was the initial confusion about the Americanised

terms as opposed to Australian terms used in the model. Feedback from the

case studies was that the use of terminology customisation could defeat the

standardising effect of a reference model. This example reflects the comment

of Gulla and Brasethvik’s (2000) that variation of models complicates the

formation of a common understanding of the domain. Depending on how

broad the scope of the standardisation of terms is designed to be, the

overuse of the terminology matching dictionary could still be of great use. For

example, the use of terminology variation might not be appropriate if the

major aim of the model is to align a whole industry, but may well be useful to

match the terms to that of a single organisation that is using the model.

The coding in Table 16 and the context in which the models were discussed

confirms the importance of economic efficiency in the quality attributes or

dimensions of reference material. Quality aspects such as Application

Documentation, easily understood, easily accessible, have a simple

language etc are all examples of quality attributes that can aid the economic

efficiency. The desire for guidance on how to use the models (e.g.

implementation guides, case studies) and aspects that would reduce the time

and effort to understand and communicate the reference model (e.g. simple

to understand language) support this “economic efficiency of use” concept.

Our findings indicate that an important quality attribute or even a quality

dimension from the viewpoint of the user of a reference model is the

economic efficiency of the use of the model, a separate concept to the

previously mentioned economic efficiency of the design of the model. This is

a separate economic efficiency to that mentioned in the literature, which

discusses the economic efficiency of the design process; the two concepts

are not necessarily related.

The relationship of these concepts is depicted in figure 34.


QUT Page 107

Figure 34: RM Lifecycle related to the types of economic efficiency

4.10 Limitations and Conclusions

A limitation of this research is external validity, with only 2 case studies. This

chapter has presented the empirical findings of two case studies aimed at

determining the quality attributes of business process reference material.

This research is not, and is not intended to be a definitive study on the quality

of business process model. It is only an exploration of the user perceived

attributes of quality. It is intended to provide a basis for further work in the

area. Another limitation is the use of the frequency of citations as an

indication of the perceived importance of the various attributes. Again this

should be taken as indicative only and requires further work to test the

relative importance and completeness of the attributes. The use of

perceptions of quality only and not other more objective means such as direct

comparison is another limitation. However, direct comparison should be done

on proven quality criteria, derived from exploratory research such as this

paper. Also as mentioned in Krogstie et al. (1995) it is difficult to measure

quality directly, particularly semantic and pragmatic quality and as a

substitute for direct measures perceptions are a valid measure.

In conclusion the consistent use of terminology, a simple or simply

understandable modelling language, and a complete, accurate and ideally

tested, content were all results that had been mentioned previously in the

literature, although not extensively empirically explored or proven. Findings

Design Reference

Model

Reference

Model

Use Reference

Model

Efficiency of design

Efficiency of use

Quality Attributes


QUT Page 108

that were not mentioned in the existing literature or contradicted it included

the issue that reference models should be complete at the expense of being

relevant to a particular audience, and the need for a feedback mechanism

either through training or some other means. An interesting new idea

expressed throughout the case studies was the idea of customisation of the

terminology used in reference models. The original framework was found to

be lacking in that it did not contain aspects of economic efficiency,

particularly of the cost of use of the reference model.

Based on these results, further exploration of the quality of reference models

should be conducted particularly from differing points of view (e.g. from the

model producer’s view). In this further research we would expect that the

economy of design and, particularly if the reference model is living, the

economy of maintenance to be important quality factors.

Figure 35 summarises the conclusions that differ from or add to the existing

literature on the quality of models using the particular perspective in this

research. The major reasons for the differences found in this research to the

current literature probably stem from the slightly different unit of analysis (i.e.

reference models versus models in general) and the perspective taken on

quality (i.e. user view and business process modelling purpose versus

general quality drawn largely from modelling for the purpose of designing

computer systems).

Figure 35: Conclusions that add to or differ from current literature

Syntactic Quality • Glossary • Simple

Semantic Quality • Scope and

limitations • Validation of

models • “Over-

completeness”

Pragmatic Quality • Application

documentation • Vendor training • Feedback

mechanisms

Economic Efficiency of Use


QUT Page 109

The choice of case study organisations may also have been a limitation to

the external validity of the findings. The two organisations were engaged in

process modelling, however in both cases these modelling projects were not

very large in scope or size and did not use a formal modelling technique or

dedicated tool. As such the lack of language formality (as defined in

Chapter 2) in the models may not have presented any problems as it may

have done if the modelling efforts were conducted in a more systematic and

syntactically formal manner. The models were used for a semantic basis

only, not as true templates, so the aspects of quality may be different

depending on the type of derivation. Because the models were not used for

an IT implementation, the demands for a formal language were also reduced.

Further work in other case studies or a survey encompassing a larger sample

would be required to validate the findings of this study. We believe that this

paper has laid the exploratory foundation for further empirical research into

the area.

4.11 Chapter Summary

This chapter has explored the quality of business process reference models

from the perspective of those using the reference models for process

modelling. It is designed to offer reference model producers guidance on

what factors are important to the perceived quality of their reference material

as perceived by the model users. As mentioned in Chapter 3, the case

studies and analysis were concluded in parallel. The study findings benefit

future research in the domain of reference models and more specifically on

reference model quality. The study findings is of value to the practitioner who

applies business process reference models, as the findings can be used in

the selection and evaluation processes of reference models.


QUT Page 110

Chapter 5: Reference Model Design Procedure

5.1 Introduction

This chapter outlines the proposed procedure for the design of a reference

model.

Figure 36: Chapter 5 in relation to the Reference Model Lifecycle

The term procedure is used here to indicate a project (as differentiated from

a continuous or operational process.

There has been very little academic literature outlining a procedure to design

a reference model. In fact, there were no articles specifically describing the

procedure of the design of a reference model, although several mention the

time and effort required to design a reference model.

An example from Germany gives an indication as the time and resource

commitments necessary. The construction began in April 1999, consisted of

seven project subgroups, several steering committees, and more than 100

university employees with a total of 30 consultants and instructors from

Mummert & Partner, Debis, and SAP SI. One of the project goals was to

develop a reference model for financial processes at German universities

and 2 years later went live with only parts of the FI and Funds Management

modules (Anonymous 2001).

Design Reference

Model

Reference

Model

Use Reference

Model


Quality Attributes


QUT Page 111

Inferences can be drawn as to the effort and personnel required to produce a

reference models by the number of authors. For example reference models

such as SCOR, eTOM and ITIL have up to several hundred listed authors

and many more contributors.

As can be seen by these numbers the design of reference models can be a

long, and therefore presumably expensive, procedure involving many man-

weeks.

The next section identifies the design philosophies for reference models. In

reality the creation of a specific reference model may be based on many of

these philosophies, however an explicit description of each may clarify the

options available to reference model designers.

5.2 Reference Model Design Philosophies

Having found no detailed theory on how to design a reference model, several

design philosophies, or methods are proposed.

We also propose that the design philosophies chosen for a particular

reference model design should be influenced by the purpose and intended

audience of the model and proposed characteristics of the model, particularly

the Readiness for Use (e.g. single depiction, contains variant) and State (i.e.

best or common practice) characteristic. The design philosophies are

presented here as formalised and discreet approaches. However, in reality,

the actual design of a reference model would consist of many trade offs and

fluid combinations of these approaches. Indeed, the decisions described in

this section may not be made consciously or explicitly, but rather are part of

the “black-box” of reference model design.

Many of these design philosophies rely on the accurate identification of the

appropriate existing enterprise specific models, reference models or other

information (collectively termed the information entities for this discussion,

see Figure 37 for examples), and the accurate comparison of these

information entities to determine which parts of the entities correspond to

each other and whether each part is relevant to the reference model being

designed. These three steps, identifying relevant information entities,


QUT Page 112

identifying the relevant parts (or sub-entities) of these entities, and comparing

these sub-entities, could be particularly difficult and may not be based on

scientific or explicit manner. This design procedure is essentially creative

and, as such, often unstructured, relying heavily on the modellers’

interpretations of the information entities, other subjective decisions and the

pressures of time and resources available during design.

Figure 37: Examples of possible information entities

Each of the philosophies is identified below and their advantages and

disadvantages are briefly described.

5.2.1 Blue Sky Design

This design philosophy is extremely creative and is based on the original

concept of BPR. It intends to design a reference model without relying on

other sources, such as the existing models in the domain. Reasons this

philosophy may be used include the absence of any other information, or a

desire to be freed of the constraints on creativity sometimes associated with

going through the design process with existing ideas and/or constraints. This

process could be challenging and may ignore existing good applicable ideas

or unavoidable environmental constraints; essentially it may be a case of re-

inventing the wheel. Alternatively, the resultant reference model may contain

unconventional, visionary, and innovative ideas.

Reference model to be designed

Case Studies

Surveys

Tacit Knowledge

Focus Groups

Other Reference

Models

Academic / Trade Papers

Existing Products

Standards


QUT Page 113

A model of this type may serve as the ideal long-term goal within an industry

or organisation.

5.2.2 Design by Choice

There are two types of design by choice. Firstly, a model may be declared as

a reference model because it is seen as the best in the domain. The second

type of design by choice is the arbitrary selection, when the choice is

influenced by external forces that effectively dictate which model is the

reference model. An example of this, linked to the implementation of

Enterprise Systems, would be the use of a model of head office processes to

design and implement the processes at any subsidiaries or local offices in an

international organisation. This could enforce or improve standardisation

efforts which are based on a known working implementation.

Both of these types of Design by Choice transfer the status of “reference

model” onto an enterprise specific model. This method is commonly used

when organisations are identified as having “best practice” in a particular

area, where their model is taken as the reference model for that area, which

could then be used for applications such as benchmarking.

5.2.3 Baseline Design

To produce a reference model using the Baseline design approach, several

steps are required. Firstly, information from various sources detailing the

target domain would need to be identified. These information entities could

include other models, “expert” opinions, academic and trade literature,

standards or any other definitions or representations.

Once the entities have been identified they have to be related to match like

concepts within the information entities. Once this identification and

comparison of these information entities has been completed, the existence

of these sub-entities can be related. In the Baseline Design approach like

sub-entities that did not appear in sufficient numbers across the information

entities could be excluded.


QUT Page 114

Using this approach the identification of suitable information entities is crucial

to the outcome, as is the selection of the reference model scope. The

resultant reference model reflects the maximum commonality of the domain

or in mathematical terms the highest common denominator.

Figure 38: Baseline Design

In the example shown in Figure 38 the sub-entity must occur 80% or more of

the information entities for it to be part of the reference model.

5.2.4 Common Practice Design

Similar to the Baseline Design, this approach starts with the identification and

comparison of the information entities and considers the number of times

sub-entities appear in the information entities. The highest occurring sub-

entity is then chosen for the reference model.

Reference Model Relevant Parts of Information Entities


QUT Page 115

Figure 39: Common Practice Design

Advantages of this philosophy include the fact that the reference model

reflects the most common implemented solution for a particular domain. This

could then be used for standardisation activities. Many parties will be able to

relate to the reference model, which could make it more generalisable. A

reference model designed this way does not contain any radically new ideas.

5.2.5 Best Practice by Composition

Again starting with the identification and comparison of the relevant

information entities, this philosophy is an attempt to provide a “best-of-breed”

approach to the reference model. When information entities are in

disagreement a method (for example case study, statistical analysis of

implemented occurrences, survey, experience) could be used to determine

the “best” solution. This may be a matter of choosing the best solution or

combining existing solutions to produce the best practice. This method of

composing sections of existing information entities to form a reference model

may be extremely difficult and subjective as the information entities may not

have clearly defined points which could aid integration, and often may not be

depicted in the same modelling language. This would involve a certain

amount of interpretation on the part of the model designers.



QUT Page 116

Figure 40: Best Practice by Composition

Figure 40 depicts how certain sub-entities can be combined in a reference

model to capture best practice by composition.

This method could involve merging information entities to produce a new

idea, which is depicted graphically above in the second reference model

object. Advantages of this method is that new and innovative ideas can be

built into the model, although disadvantages may include the effort involved

in design, and the fact that the generalisability of the reference model may be

low because of the cost of implementing all the best practice ideas, for

example several of the best practice information entities may be built with

different IT systems, making the integration of these point solutions a

requirement for the implementation of the reference model in its entirety.

5.2.6 Design by Abstraction

This approach requires a set of relevant information entities to be identified.

After the comparison of these entities, the Design by Abstraction approach

would create the reference model at such a high conceptual level that all the

variations are accounted for within the higher constructs.



QUT Page 117

Figure 41 shows a graphical depiction of this design philosophy, the blank

square is a depiction of “a symbol” which is the abstraction from the circles

and hexagons in line 4.

Figure 41: Design by Abstraction

Figure 41 depicts how the reference model can be abstracted from the

Information entities, by capturing only what is common in all the information

entities.

This approach produces a reference model that is very general, and could be

applied to many circumstances, but one with lacks the level of detail of the

original entities. It requires the model designer to decide the point at which

the advantages of having a highly generalisable model are outweighed by the

disadvantages of a model lacking lower level detail, as depicted in Figure 42.

Reference ModelRelevant Parts of Information Entities


QUT Page 118

Figure 42: Relationship between Benefit vs. level of abstraction

The exact curves on the graph are determined from the intended use and

audience of the model.

An apparently obvious solution of combining both the high level models

created by this method and lower level models created using any of the other

models does not adequately solve the problem. This is because the lower

level (higher detail) models require more specific context, decreasing the

benefits from generalisability. The higher level model could be used widely,

but the lower level models could only be used in a specific domain. What is

advantageous is a model with a single high level picture, but with several

solutions at the lower level that can be selected to fit the specific domain, that

is, an Explicit Alternatives Design.

5.2.7 Explicit Alternatives Design

This philosophy uses the same identification and comparison of information

entities as described above. In this case however, differences between the

information entities are captured in the model in an explicit way, allowing the

reference model user to select the appropriate alternative when instantising

the reference model.

Level of Abstraction

Benefit of Generalisability

Benefit of Level of Detail

Ben

efit


QUT Page 119

Figure 43: Explicit Alternatives Design

The explicit alternatives design philosophy provides an interesting benefit of

combining the benefits of being widely acceptable, while still containing the

detail to make it useful at a lower level of abstraction. Disadvantages include

the cost to produce such a model and the fact that the model is not “ready-to-

run” i.e. it requires configuration before it makes sense at an enterprise level.

This second disadvantage could be over come if the model had default

configurations. At present this only relatively simple examples of this type of

feature has been found in existing reference models (e.g. SCOR), using a

functional explicit alternatives, but not any process examples of explicit

alternatives.

5.2.8 Design Philosophy Summary

Most of the philosophies presented here could also involve some aspect of

weighting of different information entities, based on information such as

timeliness, relevance, perception of excellence or trends.

The weighting could help reference model developers quantitatively skew the

design procedure to ensure the reference model focuses on the important

entities. An example situation where this could be advantageous could be a

software developer developing a reference model for the development of a

Reference Model

or

or or

Relevant Parts of Information Entities


QUT Page 120

new off-the-shelf product, but wanting to make sure that the product

adequately supported the processes of its more valuable customers.

5.3 Reference Model Design Procedural Model

With the absence of any guidance, the reference model design procedural

model was designed as depicted in Figure 44. The model was based on the

general procedure for process modelling gaining validation for each model

while increasing the level of detail. In any modelling project, including

producing a reference model, the procedure needs to be flexible. This is

particularly true with respect to the modelling conventions.

In the following pages each of the steps of the proposed procedure are

described.


QUT Page 121

Figure 44: Proposed BP Reference Model Design Procedural Model

DesignHigh-Level

ValidateHigh-Level

TestHigh-Level

DesignLow-Level

ValidateLow-Level

SelectLow-Level

TestLow-Level

No changesmade

Low Level OK,RM finished

DefineReference

Model

Changesmade

Low Levelchanged

Low Level OK,RM notfinished

Reference Model to be

designed


QUT Page 122

5.3.1 Define the Reference Model

Outline Purpose of Model

This is closely linked to the purpose of the model. Not only is defining the

purpose of the model extremely important for the users of the model, it is also

important as a guiding point when creating the model. Closely linked to

purpose is the clear definition of the scope and limitations of the reference

model. This is one of the quality factors that is rated very highly as discussed

in Chapter 4.

Select Model Characteristics

The selection of model characteristics is important for several reasons as

explained in 2.3.

Firstly, it allows the developer to position the model with respect to any

existing works, therefore possibly allowing the reuse of other model contents

or structure. It also provides a clear view of the end product of the reference

model to allow consistent model design.

Many factors are important in choosing the characteristics. The three most

important aspects are the desired end use of the model (the purpose), the

proposed audience of the model and a group of considerations which is

termed the ‘business factors’.

These business factors include how or if the model production costs are

recouped, how the model is distributed and what support in terms of training,

feedback capabilities etc. are provided; essentially the business plan behind

the reference model. These factors are not discussed in this thesis.

Develop Modelling Conventions

Developing modelling conventions reduces the numerous different possible

applications of the modelling technique. Modelling techniques or languages

usually only contain a part of the rules required for a consistency in the

layout, terminology, naming and content. These types of consistency have

been shown to be amongst the most important quality factors for end-users

of reference model as discussed in Chapter 4.


QUT Page 123

During this stage, the terms used in the model should be set up and

constantly updated during the rest of the reference model design to reflect

any changes made. This provides a glossary of the terms which was

identified as a key quality attribute for reference models in Chapter 4.

5.3.2 Design

The design step is dependant of the design philosophy or philosophies that

have been chosen by the developers, which has been discussed in 5.2.

Although these steps are described as discreet and calculated activities, the

actual design of a reference model may not be a linear and well structured

process. The steps as described here are only meant as a high level

simplified view of the activities that could be required.

Table 17 summaries which steps would be needed dependant on the design

philosophy used.

Steps

Identify

information entities

Relate information

entities Rate entities

Blue Sky

Abstraction + +

Choice + +/- +/-

Baseline + + +

Common practice + + +

Best practice (composition) + + +

Philo

soph

y

Explicit Alternatives + +

Table 17: Relationship between Design Philosophy and required Design Steps

+/- This means that the step may or may not be required


QUT Page 124

Identify Information Entities

This step involves searching for information related to the reference model.

The information collected in this stage could include tangible, e.g. other

reference models, publications from standards organisations, academic and

industry literature and intangible resources, such as experienced individuals

or organisations. Relevant information entities may include material from the

same industry as the reference model, but may also include input from

similar areas, such as using the best practice for hotel check-in for hospital

admissions.

This stage may also include searching not just for the content, but for ways of

depicting the content, e.g. languages, modelling techniques, terminology or

popular graphical depictions or ways of structuring the information about the

domain.

Once an information entity has been identified, the entire entity, or only

selected parts of the entity (the sub-entities) can be used as input for the next

step of relating the entities (or sub-entities).

Relate Information Entities

This step involves identifying which parts of the information entities (the sub-

entities) are within the scope of the reference model and then comparing the

models themselves by grouping the like sub-entities. Due to the complexity of

most domains, and of the infinite methods of capturing information, the step

of relating information entities can be quite difficult.

For example, parts of a reference model describing the processes for a

manufacturing enterprise may be compared to parts of a model for a services

firm. Relating the information sub-entities may involve realising that the

processes for “HR” in the manufacturing model cover a similar domain to the

“Personnel Management” part of the services model.


QUT Page 125

Figure 45: Depiction of the design step of Relating Information Entities

Figure 45 graphically depicts how different sub-entities can be related to

each other. Once they have been related to each other the design philosophy

determines how to combine the sub-entities into the final reference model.

Rate Information Entities

Entities could be rated through benchmarking studies, surveys, or using

qualitative measures or subjective judgements. The type and depth of the

required comparison depends on the requirements of the situation and the

resources available to the task.

Depending on the design philosophy/ies chosen the results of the rating of

the sub-entities (or entities as a whole if the Choice philosophy is employed)

determines which parts or the existing materials are re-used or modified to

design the parts of the reference model.

Build

This step involves integrating all the required parts of the information entities,

which could include thoughts, other models, case studies or standards etc. If

the information entities are in different languages, which is highly probable,

then transformation into a single modelling language is required.

Information Entity A

Relationships between Information

sub-entities

Information Entity B


QUT Page 126

5.3.3 Validate

Validation is an important step for both the accuracy of the model content

and the acceptance by a target audience. It is a way of reconciling the

opinions expressed in the model by the developers with outside experts.

Some models do this by a public release and invitation for comment e.g.

eTOM. It is also an opportunity to test the pragmatic quality of the model, by

introducing it to those who have not been involved in the design of the model.

The ability to provide feedback to the developers and an opportunity to be

educated about and question the model was also identified as important. The

validation step allows all these to happen.

Validation can be achieved by using the reference model in real projects and

assessing its strengths and weakness as perceived by the reference model

users and using these as a basis for improvement in the model.

At the end of the validation the model should be verified, i.e. ensuring that the

model conforms to the language rules and layout conventions etc.

5.3.4 Test

Prior testing of the model was an important quality attribute identified in

chapter 4. By testing we mean using the model for its intended purpose and

identifying the areas that need revision or that need to be added. Once these

areas have been identified they can be changed by the model developers,

ideally followed by a re-validation of the changes. The number of iterations of

this cycle depends on the “economic feasibility” as discussed in Chapter 4.

Outputs from the test phase could be the comments by those who were using

the model as well as the material e.g. enterprise specific Models that the

team produced. This data should then be examined for possible changes to

the reference model.

One of the quality factors identified in Chapter 4 is the need for the model to

be tested in a real life context, a platform that the testing phases provide.


QUT Page 127

5.3.5 Select Low-Level

The step of selecting a lower-level process to model is reasonably arbitrary.

Business factors such as which process would be first implemented in an

organisation or for which process there was a market demand could

influence the decision. As discussed in Chapter 4, a reference model should

be complete, meaning that all the processes shown in the high level model

should eventually be modelled to a least the same level for consistency. The

level to which they are modelled depends on the intended audience and

application of the reference model.

5.4 Chapter Summary

This chapter outlines several design philosophies for business process

reference models, namely “Blue Sky Design”, “Design by Abstraction”,

“Design by Choice”, “Baseline Design”, “Common Practice Design”, “Best

Practice by Composition” and “Explicit Alternatives”. Advantages and

disadvantages of each of these philosophies are briefly outlined. These

philosophies can be combined depending on the requirement of the

reference model under design.

The second major topic of the chapter is a proposed procedure for the

development of business process reference models, showing the effect of

each of the design philosophies on the design procedure. This proposed

design procedure is applied in the next chapter to design a partial reference

model for IT service provision.


QUT Page 128

Chapter 6: ITSP Reference Model Design

6.1 Introduction

This chapter describes the actual design of the reference model for IT service

provision. The testing of both the high-level and the lower level are presented

in the next Chapter.

As described in 5.1 the design of a reference model is quite time, labour and

knowledge intensive and due to time and resource restrictions of the

research team and invited participants only one cycle of the design

procedure was completed.

6.2 Define the Reference Model

6.2.1 Model Purpose

A reference model may be applied for difference purposes; however it is

necessary when creating any model to have a specific purpose in mind. Most

business process models have been mentioned in literature as a tool for

business process re-engineering or business process improvement (BPI) as

discussed in detail in 2.6 e.g. (Rosemann et al. 2003 p27). This reference

model is therefore aimed at supporting this BPI purpose. Specifically, it

should be useful as a process identification tool, a TO-BE template and to a

lesser degree an AS-IS template.


QUT Page 129

Figure 46: Purpose of the developed ITSP Reference Model

6.2.2 Model Characteristics

This section outlines the characteristics that were chosen for the model,

along with a short explanation and justification.

View

As explained in the opening chapter, the process view was selected for the

reference model. The process view was selected because business process

management has been successfully applied in other areas and types of

organisations, for example manufacturing or accounting, but is still relatively

immature in the IT service provision domain (Williams 1997).

Language

A graphical standard language has been chosen as the basis for this

reference model, namely the extended Event-Driven Process Chains (eEPC).

Most models within IT service provision rely heavily on natural language,

indeed early process models have employed narrative text and/or structured

Instantise for Process Identification

High-Level Template

Process Targeting

Instantise for AS-IS Modelling

AS-IS Template


Instantise for TO-BE Modelling

TO-BE Template


Process Execution

Monitoring/Control


QUT Page 130

textual descriptions (Curtis et al. 1992). However, one of the major quality

factors in models in general is consistency (Lindland et al. 1994; Krogstie et

al. 1995; Becker et al. 2000). As shown in Chapter 4 consistency is also

highly important in business process reference models.

In another field, much work has been done to improve the process of

transforming natural language requirements into formal models that are more

suitable for system design e.g. (Kang et al. 2002). Natural language is not

ideal for system development because it is prone to being unstructured,

having gaps in information and containing inconsistencies (Ryoo et al. 1999;

Fabbrini et al. 2000).

Combining these two facts, i.e. that business process reference models need

to be consistent and that the use of natural language can easily generate

inconsistencies, it is a small step to conclude that natural language is not the

most suitable language for a business process reference model and hence a

semi-formal language backed with textual descriptions is used.

The use of a graphical language makes the model more accessible by a

wider audience and provides a basis for software design if the users of the

model wish to use it for this purpose.

State

Many descriptions of current practice facilitate the development of standards

particularly with respect to electronic communications or interfaces (for

example the ISO-OSI or other technical telecommunication and IT

standards). The model to be designed describes best practices in IT service

provision. The term ‘best practice’ always produces controversy. It is used

here to indicate that the processes described in the model are the commonly

accepted current viewpoints on what would be the best way to perform the

activities, with none of the common constraints that restrict ‘current’ practices

such as lack of integrated tool support or lack of resources such as

experienced personnel or organisational or even industry cultural legacies.

Other terms that are similar to “best practice” are “good” or “accepted”

practice. The reason that a depiction of best practices as opposed to


QUT Page 131

common practices has been chosen is that there is a general

acknowledgement that current practices in IT service delivery can be

improved. Also as mentioned earlier common practice models are often used

to allow interconnection and communication, neither of which are the goal in

this case.

Focus

As is already apparent, the focus of the reference model to be developed is

on the business side of operations. In particular it looks at selected business

processes of the IT service provider organisation.

The business processes are those processes that provide value for the

customer. They typically involve people and decision making using business

rules or policies and the use of IT applications or other forms of structured

data to support the process.

Level

The models to be developed were Complete, Intermediate and Task. The

reason all the levels of the model were presented stemmed from the original

discussion of reference models for this domain. They either lacked detail or

lacked consistent integration. The model was designed to show how the

levels of detail can or should be integrated. This integration the hopefully

overcomes ITIL's major shortfall of inconsistency.

The intermediate models were the higher level (level 0) models that

described all the processes of an IT service provider. This level forms the

basis from which process improvement targeting could be achieved, as well

as providing an overview of the organisation. At this level, organisational

units and process owners could be attached to processes allowing tactical

decisions to be made.

The Intermediate level models (Level 1) describe the basic steps of each of

the processes while the Task level models (Levels 2+) describe the detailed

breakdown of the processes. They provide detailed guidance on how the

processes should be performed, what systems would be employed and the


QUT Page 132

description of the interactions between the organisational units and

individuals. At another lower level the technical steps performed by the

systems are also explained. The model was designed to depict this level of

detail to facilitate the analysis of IT support for the process and to provide

guidance to individual employees.

The hierarchy of the model is shown in Figure 47.

Figure 47: Interaction of Levels of Abstraction

Functional Area

The model can be seen as either a functional area specific model in IT or as

an economic activity specific model for IT outsourcing. The model is

classified in this discussion as the economic activity specific model, therefore

making it a Function Area of the model “enterprise”.

The model’s core is the IT service provision core processes, and, while the

model recognises the existence of other activities such as strategic

management or the support processes, it does not examine them in any

depth or detail.

Theoretically, the model could also be applied to in-house IT service

providers. In fact due to the trend toward more accountability in IT in-

sourcing, many in-sourced IT providers are mirroring the processes of the

1 2 3

2.1 2.2 2.3 2.4

2.2.1 2.2.2 2.2.3

Incr

easi

ng L

evel

of D

etai

l

Level 0 Complete

Level 1 Intermediate

Level 2+ Task

…

…

…

…


QUT Page 133

outsourcer (Willcocks et al. 1997). This division between the internal ITSP

and its host organisation may not be as advantageous when part of the IT

being provided is actually the core business of the host organisation.

Economic Activity

The model was developed as a depiction of an IT service provider

organisation. As such the industry would be IT, making the model a specific

economic activity model. As discussed above however, the models could

easily be used, in an internal service provision situation (an IT “shop” or

department). This would be particularly true in an organisation with a

centralised IT environment or one that used internal billing as a method of

management and control.

There were several reasons this domain was chosen.

Firstly, existing literature, particularly eTOM and ITIL, covered the domain but

did so in a way that was unsatisfactory for the purposes described above

(see 2.8 ITSP Business Reference Models for this discussion and 6.2.1 for

the purpose of this model). However, these models provide material for the

design phase of the model which can offset the lack of knowledgeable

resources available to the research.

IT service provision, in contrast to many other functional areas is relatively

young, with IT only being used extensively and pervasively to support

businesses relatively recently5. Hence, there is an opportunity for greater

improvements by formalising the process than there is by focusing on

established areas such as accounting, logistics or manufacture etc. This

combined with the established use of modelling to design IT systems makes

the application of reference modelling to the delivery of IT services an

academic and practical challenge.

5 The first commercial electronic calculator was released in the 1960’s, ERPs in the 1980’s, compared to accounting which has been used for over 2000 years (Williams 1997).


QUT Page 134

Tool Support

As described previously the language of the model is eEPC. The decision to

use this language was partly due to the tool support available for the

development and distribution of models developed in this language. Having

tool support was one of the quality factors which were mentioned in

Chapter 4.

The tool package, produced by IDS-Scheer, has been rated “leader” in

Business Process Tools by Gartner (Anonymous 2002). The ARIS Toolset

allows a consistent approach to modelling. It does this in several ways,

mostly by relying on the database backend of the package to deliver

consistent naming and usage of defined objects. Consistency is one of the

most important aspects of a reference model, as described in Chapter 4

A major reason for the choice of the dedicated modelling tool was the

existence of in-built consistency checking functionality. ARIS Toolset already

came with predefined and accepted depictions of the building blocks of

models in the language. It also allowed for the easy distribution of the

developed models and the accurate interfacing between the models. Another

attraction of this toolset in particular was the incorporation of the different

languages selected in the model development, value-added chains and

eEPC. The author’s previous experience with both the tool and the language

were also influencing factors. The current availability of several other

reference models in the toolset provides a proven track record, for the

development and ultimately use of using ARIS as a tool for reference

modelling.

Readiness for Use

The model is a single depiction type model. The model makes several

assumptions about best practice that could vary with the specific situation in

which IT services were being provided. These assumptions are discussed in

Chapter 8. With greater resources variants could be added, depicting a

different process for the different assumptions, for example the different

processes for external vs. internal service providers.


QUT Page 135

Other Characteristics

Characteristics that are to do with the distribution and commercialisation of

the reference model have been excluded because they are not relevant to

this research project. In Table 18, the characteristics that have been chosen

for this model are presented. Due to time and resource constraints no

extended content is provided, however it is expected that the ITIL books

would provide substantial extended content. There are no plans at this stage

to make it a living reference model although there is no reason, other than

the requirement for resources, that this could not occur.

The characteristics of the derived reference model for ITSP for this research

is summarised in Table 18.










Tool Support Producer Supplied Third Party Supplied Public Domain


Table 18: Summary of ITSP Reference Model Characteristics

6.2.3 Modelling Conventions

The modelling conventions have been modified by the input from the focus

groups particularly in relation to the scope of the model. The final modelling

conventions are presented in this section.


QUT Page 136

Model Scope

Using the taxonomy of IT services presented in 2.7.2 and the lifecycle of IT

services presented in 2.7.3 the model is positioned as depicted in Figure 48.

Figure 48: Scope of the ITSP Reference Model

As shown in the Figure 48 (derived in Chapter 2), the model is focusing on

the “Delivery and Support” or the operations phase of the IT Service

Provision lifecycle and on “Service Delivery” and “Infrastructure

Management” in terms of the market taxonomy. This simplified lifecycle

model does not differentiate between the first cycle of service support, which

would include the initial planning and setting up of an entire IT system,

versus the progressive planning and implementation of single applications,

which could happen quite frequently. The model developed acknowledges

that even within the “Support” phase, new applications and systems is

planned and implemented. The model specifically excludes the development

of a new application, because other models have dealt with this area and this

is not the focus of this research. It does however include the processes that

Plan

Implement

Support

Retire

Solution Delivery

Service Delivery


Network Management

a) IT Services Taxonomy

b) IT Services Lifecycle

Scope of Model


QUT Page 137

take the developed application and release it into the production

environment.

The two market layers of Service Delivery and Infrastructure Management

were chosen because the feedback from the initial focus groups and the

review of the literature suggested that large IT outsourcing vendors operate

in these two layers.

Most IT outsourcers offer services in the solutions delivery domain, but

feedback from the focus groups indicates that while these products and

services are often offered they are very rarely utilised.

Modelling Methods and Tool

The modelling package ARIS Toolset was chosen for the design of the

reference model. The Toolset offers a range of modelling techniques one of

which is the Value Added Chain Diagram, used for the mid-level modelling,

and extended Event-Driven Process chains (eEPC), which is the chosen

method the modelling language at the lower levels.

eEPC – Level 2+

Event driven process chains show the chronological-logical procedure of a

process (Anonymous 2002 p4-103). This process modelling language is

driven by events. Events are defined as “the existence of a state”. The events

trigger and are created by functions. A function is a unit of work.

Object Types

The following object types and their descriptions have been adapted from the

ARIS Methods Manual (Anonymous 2002).


QUT Page 138

Symbol Object Type Name Description

Event Events trigger functions and are the results of functions.

Function A function is a technical task or activity performed on an object

IT Function IT Functions are those functions that are

completed automatically by the IT application.

Process Interface

A process interface indicates from which process the related event has been created, or which process the event

triggers.

Rules X-OR AND OR

The rules describe how the events and functions can be related.

The X-OR means that one and only one input/output is possible, the AND that all

the inputs or outputs must be true, and the OR states that any combination may be

possible.

Person Type

A person type represents the typification of individual persons which have the same

characteristics. These characteristics may refer to similar authorizations and

responsibilities, for example.

Application System Type

The application system type is representative of a related group of IT

systems that have the same functionalities.

Table 19: Object Types for eEPCs

Naming Conventions

Events are generally named following the format of “noun” “verb” e.g.

“Incident Recorded”. Functions are named “verb noun” e.g. “Detect Incident”.

Maintained Attributes

The maintained attributes of the objects are shown in Table 20.


QUT Page 139

Maintained Attribute Information contained Descriptions/Definitions Gives a general description of the object

Source This shows from where the ideas for the particular part of the model originated.

Remark/Example Gives examples or further explanatory information Table 20: Maintained attributes in eEPCs

Connection Types

The connection types in the eEPC’s are summarised in Table 21.

Connection Type Description Leads to the function produces the event activates The event triggers the function

Is evaluated by The rule decides the process flow

Contributes to An organisational unit that is involved in but does not execute a function

executes The organisational unit that executes the function Table 21: eEPC connection types

Model Layout Convention

The eEPCs have been produced to show the “error-free” path as close to the

centre as possible, flowing down the page. An error-free path is the path that

an ideal process instance should take. Error or exception conditions are

shown as a branch out form this error-free path. An example of this is shown

in Figure 49. At branching points that do not have a clear error/non-error

situation the paths have been split symmetrically around the centre.

Figure 49: Example of error/non-error process split depictions

Configuration details correct

Check configuration

details

Configuration details

incorrect

X


QUT Page 140

Omitting Trivial Events

After feedback from the focus group, in which an eEPC strictly adhering to

the event-function-event ordering of objects was shown, the trivial events

were seen as adding un-necessary clutter to the model. This provides an

example of the results of case studies presented in Chapter 4 that state that

the language used must be easy to understand. The omission of trivial

events for the eEPC technique is also discussed by Scheer (1998) and is

facilitated in the Diagram Explorer part of SAP’s ValueSAP.

Therefore all trivial events have been removed from the models. An event is

deemed to be trivial if all of the following conditions hold true:

• the event occurs every time after the execution of the function

• the event does not mark the start or end of a sub-process or the start

or end of a process or process step as defined by the value chain

An example is presented in Figure 50.

Figure 50: Example showing removal of trivial event

Combining Optional and Mandatory Paths

In the situation where the process continues and also may trigger another

process path an OR operator is used. The mandatory path is shown centred,

while the optional path is shown as a branch as in the example in Figure

Classify Incident

Accept Incident

Classify Incident

Accept Incident

Configuration details correct

Event removed


QUT Page 141

51(a), where the Service Level Agreement is assigned regardless of the

outcome of the threshold check, and the threshold check may produce the

event “Threshold exceeded”. Alternatives of modelling this situation in a

strictly syntactically correct method are shown in Figure 51(b)I, ii and iii.

Figure 51: Combining Mandatory and Optional process paths

(a) Modelling convention

(b)i Formally Correct Representation

(b)ii Formally Correct Representation

CheckThreshold

Thresholdexceeded

Assign ServiceLevel Agreement

RecordSymptoms

RecordSymptoms

CheckThreshold

Thresholdexceeded

Threshold notexceeded


Notify ProblemManagement

CheckThreshold

Thresholdexceeded



RecordSymptoms

(b)iii Formally Correct Representation

Threshold Checked

CheckThreshold

Thresholdexceeded



RecordSymptoms


QUT Page 142

The decision to use the slightly less formally correct option (a) was to make

the models less cluttered and to make the language easier to understand.

The first syntactically correct version (b)i involves a consecutive combination

of two types of connectors that requires reasonable understanding of the

modelling technique to interpret. The second correct form of modelling the

situation is shown in (b)ii, it involves 50% more objects than the proposed

form. The third syntactically correct depiction (b)iii, shows a slightly different

semantics, indicating that as soon as the “Record Symptoms” has occurred

the Service Level Agreement can be assigned. All of the “correct” depictions

contain extra objects, and are potentially more difficult to understand quickly

and easily, which was one of the indicators of quality identified in Chapter 4.

Process View - Value Added Chain Diagram (VAC) – Level 1

The Value Added Chain Diagram (VAC) originally proposed by Porter (1980)

is a simple form of modelling that shows the successive functions that make

up a process. It usually shows a higher level of abstraction than the eEPC

notation, depicting about 5-10 major steps in the process. It can also be used

to show levels of the functional hierarchy. In the reference model it is used to

depict the level 1 process of Incident Management. Incident Management

has a logical sequential flow of activities that makes the use of a value chain

appropriate. Other ITSP processes may not have this logical flow, and may

be more accurately depicted in other modelling techniques such as a function

tree. Because this research focused on the Incident Management process,

the other modelling techniques are not explored.

Object Types

There is only one object in the value chain; the function object type shown in

Table 22.


QUT Page 143

Symbol Object Type Name Description

Function Functions in the VAC indicate high level steps of a process

Table 22: Object Types for VAC

Connection Types

There is only one connection type in the VAC described in Table 23.

Connection Type Description Is predecessor of Means that the value chain step is performed before the next step

Table 23: Connection Types for VAC

Maintained Attributes

The maintained attributes of the VACs are shown in Table 24.

Maintained Attribute Information contained Descriptions/Definitions Gives a general description of the object

Table 24: Maintained Attributes for VAC

Model Layout Convention

Processes that have a logical sequential nature are shown from left to right.

Functions that do not have a logical place in the process are shown top to

bottom as in Figure 52.

Figure 52: Example of layout of non sequential VAC steps

Business Process Framework – Level 0

The business process framework is the highest level in the model. It is a free

form model, with no underlying modelling technique. The framework should

contain all the functions of the IT service provider.

1 2 3

A


QUT Page 144

It is divided up into process groupings similar to those used in eTOM. eTOM

uses the concept of the supply chain with customers at one end of the model

and suppliers at the other. In the other dimension the model uses a concept

of lifecycle time, which is also related to the strategic vs. operational

continuum. These two dimensions are reused in the ITSP reference model at

the process groupings and, to a lesser extent, the level 0 view.

Figure 53: Dimensions in the ITSP Level 0 view

Model Hierarchy Structure

The models hierarchical structure is based on that used in eTOM and SCOR.

That is, a top level model which, under each object, contains increasingly

detailed models. The top layer is termed Level 0, and each increasing level of

detail increases the number of the level. Figure 54 depicts this.

1 2 3

2.1 2.2 2.3 2.4

2.2.1 2.2.2 2.2.3

Incr

easi

ng L

evel

of D

etai

l

Level 0 Complete

Level 1 Intermediate

Level 2+ Task

…

…

…

…

Strategic processes

Operational Processes

Customer facing

Processes

Supplier facing

Processes


QUT Page 145

Figure 54: Model Hierarchy Structure

In the models developed there is no sharing, i.e. the hierarchical relationships

were strictly 1:m. However, with the further development of the model it is

conceivable that sub-models could be re-used in various high-level models.

When this re-use is appropriate the modelling conventions should be

changed slightly to incorporate the structure of these shared models.

6.3 Design and Validate High-Level Process Framework

The loop between the design and validation step occurred 2 times for the

high level model (Level 0), by the end of the second validation the

participants and researchers were satisfied that a level of economic efficiency

of design had been reached. This section combines the Design and

Validation phases for the Level 0 model.

6.3.1 Design Philosophy

Due to the purpose of the model, that is to provide a best practice reference

model to be used for Business Process Management, which can also be

applied to the evaluation of a software package to support ITSP, the main

design philosophy adopted by the research team is a combination of Blue

Sky and Best Practice by Composition design, much of the material is drawn

from ITIL, due to the lack of other information sources containing the detail

required for a Task level model.

The two design philosophies used in conjunction, allow good existing ideas,

usually point solutions, to be combined in a way that integrates new with

existing ideas. This applies to both the content as well as for the ways of

expressing it.

A graphical way of representing the combination of the two design

philosophies is outlined in Figure 55.


QUT Page 146

Figure 55: Combining Blue Sky and Best Practice Design Philosophies

6.3.2 Identify Information Entities

Two main groups of information entities were identified that would be useful

to the ITSP reference model, those from literature and existing models, and

industry IT service providers.

Review of Existing Models and Literature

As presented in the literature review in Chapter 2, there are a number of

reference models for related domains. Of these models two (i.e. MoF and

Corbit) reference ITIL as a major source of input. ITIL is one of the most

popular reference models for IT service management (Morin 1999; Duffy

2001; Dubie 2002; Kara 2002) and one of the only to offer detailed process

descriptions in the public domain. It lacks a comprehensive model at the

higher levels and in the integration of the ITIL processes, as well as a method

of accurately depicting the content. This is where other model identified in

Chapter 2 are helpful. Hence at the lower levels the input of ITIL is most

relevant in the reference model design although different ideas where drawn

from other sources as explained throughout the text. The other information

sources included help desk application manuals, other models discussed in

Chapter 2 and theoretical modelling precedents drawn from eTOM

Reference Model

Sub-entities created (Blue

Sky)

…

Re-used sub-entities (Best Practice point

solutions)

Existing Information Entities


QUT Page 147

especially. The individual sources are discussed in detail in section 6.3.3 of

this chapter where they are related to the final reference model.

One of the most important sources of input came from experienced

managers currently providing ITSP to paying customers. This input was

gathered through focus groups.

In order to provide validity to the models and to provide feedback on the

modelling techniques, focus groups were designed to provide the validation

step. By gaining the feedback from organisations that are currently providing

IT services, the quality aspects such as providing a semantically correct

model and easily understood modelling language could be improved. The

focus group sessions also provided an atmosphere where the designers (the

research team) and a representative sample of the potential users could

engage in discussion and provide the feedback loop from important

stakeholders. This was identified in Chapter 4 as one of the attributes that

contributed to quality in a reference model.

Focus Groups

This section starts with the focus group recruitment, a brief overview about

the organisations involved, the focus group settings and the data collection

techniques.

Focus Group Recruitment

"A critical aspect of conducting focus groups is to specify the inclusion and

exclusion criteria for participants" (Sofaer et al. 2001). Possible participants

for this focus group were sourced from large application service provision

companies in Australia. Organisations that provided large IT service delivery

to outside organisations or, to their own companies, in-house providers were

targeting for participation. Particular attention was given to those with suitable

staff based in Brisbane. The result provided commercial and government

outsourcing organisations.

Participants were sourced initially by two methods;

1. Known contacts of the research team


QUT Page 148

2. Contacted from research into commercial and government organisations

conducting large IT service provision service delivery operations

Initial contact with possible participants was by email and if interest was

expressed then a face to face meeting was scheduled. At this first meeting

the research team provided information on the scope of the project and the

benefits of participation. (The combined project was the ‘Process oriented

administration of enterprise systems’ 6 and not only the research project

described in this thesis.) In addition we described the possible solutions to

problems with confidentiality.

Participants

The following participants contributed to the research by participation in the

focus groups; IBM Global Services Australia, Computer Science Corporation,

EDS Consulting, Mincom, Hitachi Data Systems, Deloitte Touche Tohmatsu,

Citec and REALTECH AG. IBM Global Services Australia, EDS, CSC and

Citec on their own are considered the clear dominant players within the

Australian market, claiming nearly 80% of the annual IS Outsourcing

revenues based on figures from (Benson 2002). The participants in the

research were in management positions and had job titles such as Strategic

Service Manager or Service Support Manager. See Appendix E for

descriptions of the organisations involved.

Focus Group Setting

The focus groups were conducted in a meeting room at QUT’s Centre for IT

Innovation (CITI) in a central location in Brisbane CBD. Refreshments and

lunch were provided during the focus group sessions. A PowerPoint

presentation was used to orient the focus group and participants were

randomly seated around a large table in a board room type setting.

A total of 3 sessions were held at a spacing of about 3 weeks each. The first

focus group’s topic was the high-level model, the second focus group was

6 This project was funded under the ARC Linkage program operated by the Australian Research Council with the industry partner REALTECH.


QUT Page 149

going over the changes made to the high-level model and starting the level 2

model for Incident Management, and the last session was on the Incident

Management process eEPC.

The sessions had 4-7 people in attendance and were all around 2.5 hours.

Data Collection

Data collection in focus group research used audio-taping, note taking and

the changes to the model made by the participants. The approach taken for

this focus group was to use two audio-taping machines, a dedicated note

taker and timekeeper in addition to the moderator. Immediately following the

session the note taker, timekeeper and moderator composed their main

thoughts and issues. All audio tapes from the focus group were transcribed

and checked and this information was sanitised to remove names or other

identifying information. This approach is consistent with those recommended

by (Morgan 1988; Saulnier 2000b; Fern 2001). These comments although

important were only secondary data. The suggested changes to the models

were written by participants directly onto large printouts of the model which

had been supplied at the beginning of the focus group. Proposed changes to

the models were discussed at length by the focus group, the comments both

written (on the models) and oral and the marked printouts of the models

constituted the data collection from the focus groups.

6.3.3 Build

The steps of relating information entities that described the high-level

processes of ITSP and rating these entities are incorporated into the

following discussion. The relation and rating of the identified entities was

derived from the literature review.

The scope of the model is IT service provision. This scope is quite broad and

during the focus groups the scope was refined to more closely match the

industry realities. The purpose in this case is to provide a logical structure to

classify, present and perceptualise about. It is the starting point for a user to

enter the model, providing guidance about the content and where to find the

content they are seeking, while not overwhelming the user with detail.


QUT Page 150

The development of this high-level model focuses on the core activities of the

application service provider organisation, and the support and strategic

processes are left underdeveloped. The reason behind this is that other

reference models exist which cover these areas, and the unique contribution

of this research is in the area of IT services. Hence modelling how to perform

related non-core processes for example training or financial management

would not create significant value and is largely regarded as being out of

scope.

Most of the model in terms of constructs and content was derived from ITIL

and eTOM, two existing industry reference models. These models were

chosen due to their large contributor base and industry acceptance (Dubie

2002; Kara 2002), and their relation to the domain in question.

The modelling was conducted using a top-down methodology. There were

several reasons for this; the main reason was the criticism of ITIL for not

having a consistent approach and format. Also other major reference models

appear to have been developed using a top-down approach and a higher-

level model is more widely useful than a lower level model. This research

was not aimed at developing all the lower level models and therefore the

most useful contribution in light of the constraints of the this research would

be a higher-level model with selected lower-level models.

The credited original (and certainly most popular) method aimed at modelling

the processes of an organisational entity is Porter’s Value Chain (Porter

1985). In the model, the “Primary Activities” (or processes) are the ‘value-

add’ing activities (i.e. In-bound Logistics, Operations, Outbound Logistics,

Marketing and Sales, and Service). These processes are enabled by the

“Support Processes” (Human Resource Management, Technology

Development and Procurement). The developed diagram (or process model)

is depicted in Figure 56.


QUT Page 151

Figure 56: Porter's Value Chain

Porter’s value chain was developed when the manufacturing of physical

goods dominated thinking about the firm and industries. For service

industries, particularly of an electronic nature, notions of physical logistics

and production are less important.

At the highest level Porters value chain can be depicted as in Figure 57.

Figure 57: Highest level of Porter's Value Chain

Moving from left to right the transformation of goods through the Primary

activities (and the additional value) can be tracked. Perpendicular to these

‘value-adding’ processes are the support activities. These enable the Primary

activities. Using this level of abstraction Porter’s value chain can be applied

for service industries.

Support Activities

Primary Activities

In

boun

d Lo

gist

ics

O

pera

tions

M

arke

ting

and

Sale

s

S

ervi

ces

O

utbo

und

Logi

stic

s

Procurement

Human Resource Management

Technology Development

Infrastructure


QUT Page 152

The IT services taxonomy presented in Chapter 2 forms the basis for the first

model. To match Porter’s Value Chain it is turned 90 degrees and has the

enabling processes at the bottom.

The first version of the IT service provision business process reference

model is depicted in Figure 58.

Figure 58: ITSP first version

The model is essentially the top three levels of the IT taxonomy presented in

Chapter 2.

The term “solution delivery”, was changed to Complementary to capture

expert services with a larger scope that Tao’s Solution Delivery, which was

essentially the packaging of the underlying services to present a single face

to the customer (Tao 2001). This includes services designed to supplement

or improve the other layers of the IT service and the services that reached

into the consumer organisation such as business process management or

strategic IT consultancy. The Complementary process encompassed

consulting services about how to, when to and which applications and

systems to use.

Product definition is added to show that the delivery of all IT services should

be preceded by a negotiation and definition of the services to be provided.


QUT Page 153

Product definition involves the negotiation of the service scope and detailing

of the specific service to be delivered. Application Hosting is the technical

housing and maintenance of the applications and includes the infrastructure

from which the service was provided, subsuming the infrastructure

management. Using the platform provided by Application Hosting, Service

Delivery, involves the maintenance of the system in order to provide the

specific services as promised. It also includes Service Support which

involves dealing with problems or Incidents that occur in the system from a

service degradation perspective, that is, as perceived by the client.

During this development time eTOM v2.5 was released (Anonymous 2001).

Its higher-level frameworks, depicted the supply with an “Enterprise

Management” process at the bottom, which is very similar to the Enabling

process (it includes lower level processes such as HR, Financial and

Technology management).

The Application Hosting and Service Delivery are very similar to the two

processes “Resource Management and Operations” (including Application,

Computing and Network) and “Service Management and Operations”.

Effectively it was similar to the first ITSP reference model although rotated 90

degrees left as shown in Figure 59.


QUT Page 154

Figure 59: eTOM (v2.5) Level 1 processes

One aspect present in the eTOM model that is missing from the original ITSP

model is the strategy section. Along the left hand side of the eTOM model

lies the Strategy, Infrastructure and Product Processes. The idea of long term

strategic business and product planning was incorporated into the ITSP

model as shown in Figure 60.


QUT Page 155

Figure 60: ITSP Second Version

The names and structure of the high-level processes from eTOM were not

used for several reasons. eTOM was developed for the ICT market, which, at

least in part, operates in a mass consumer market. Operating in this market

necessitates a different type and emphasis on marketing. Due to the size and

relatively long-term commitment of an IT service provision agreement,

marketing (in the traditional mass marketing concept) is seen as of lesser

importance to the target audience of the developed model. Hence, eTOM’s

“Marketing, Product Customer” process was not included in the high level

model. eTOM’s supplier management is still an important aspect in ITSP but

not as important as it is in the telecommunications industry where real time

interactions with many other telecommunications companies are an essential

part of business. ITSPs usually deal with one telecommunications supplier in

a much simpler relationship. They are essentially outsourcing the

management of complex communications relationships to the

telecommunications supplier, making supplier management a support rather

than core process and hence are not shown on the high level model.

The process naming at the lower levels was also influenced by the recently

recompiled titles and descriptions of the ITIL books, i.e. Service Support,

Service Delivery, Security, ICT infrastructure management and Application


QUT Page 156

Management. ITIL is more specific to the domain in which the model is

based.

The level 1 view was developed by adding more detail and was the first

presented to the focus group for validation (Figure 61).

Figure 61: Draft of the ITSP Model as presented to the focus group

6.3.4 Validate

The first draft of the ITSP reference model was presented to the focus group

on 18th of July 2002 and in the beginning of the next focus group on the 15th

August 2002. The first 30mins was spent orienting the participants, and

providing definitions of “reference model” and the proposed structure for the

reference model. The scope of the model was also discussed, originally the

scope statement was given as a model of “the systems and activities needed

to provide a business end-user with access to an ERP in order to derive

business benefit”.

The two views of the model were presented (the highest level process

groupings and the level 1 view as shown in Figure 61).

The initial topic that was raised by the participants was confusion about the

subject of the model. The participants suggested that, having discussed the


QUT Page 157

scope of the model further, by using the taxonomy of IT services and the IT

lifecycle, that the Product Definition grouping should be removed, as these

processes were only conducted at the beginning of a relationship, particularly

the contract negotiation. When prompted however, certain aspects of the

Product Definition were part of the operation of providing IT services to a

customer. These processes the definition of service (with process of defining

the service scope and service levels) were seen as an essential on-going

maintenance of matching the client needs to the services provided, and were

done on a regular basis, not a once off process at the beginning of a

relationship.

As a result of their comments the Product Definition was replaced by the

“Service Definition” group, which was moved from the left hand side of the

model, which was made the model appear more a lifecycle, to the top in

accordance with the top down strategic to operational flow of the model

similar to eTOMs.

The participants also indicated the arrows indicated that the model was itself

a lifecycle, as opposed to a process framework. The arrows were kept

however (later to be removed in testing where they were again identified as

unnecessary), because they were perceived by the research team to be

integral to the model, especially in relation to Porter’s value chain.

The participants also argued the model as it was presented and described

could represent all IT services, not just ERP services. They also indicated

that ERP services, in their experience, were often not provided in isolation to

other IT services. Hence the name of the model was changed from ERP to IT

services.

The Complementary services were discussed next, the focus group

suggested that, although most ITSP’s offered such services, that the uptake

of these services was so low that it was not relevant or within the scope of IT

services. These activities were also seen as more strategic issues that were

not within the more operational focus of the model.


QUT Page 158

The effect of these comments was the removal of the complementary

services group from the model.

The hosting group was renamed Service Infrastructure Hosting to distinguish

it from web page hosting, and the processes in this grouping were seen as

correct and relevant.

At the suggestion of the moderator, a distinction in the two groups of the

customer was added, to aid discussion. The focus group members

suggested that there were in fact two distinct customer groups, the clients,

i.e. the managers of the customer organisations who controlled the budgets

to be spent on outsourced IT and the user group, the actual business

operators who consumed the IT services.

After identifying these two groups in the consuming organisation, the model

was re-arranged, to show which processes targeting which customer group.

In keeping with the top to bottom flow of the model from strategic to more

operational, the clients, those controlling the budget, were situated at the top

of the model. In keeping with Porter’s value chain idea, to the right of the

model where all the customer facing processes were placed (see Figure 62).

After discussing the re-arrangement, several processes that were not

discussed in the draft model were identified including Reporting and Billing.

These processes were grouped into a new process grouping called

Customer Relationship Management.

Feedback from the participants indicated that the service support functions,

were an important part of IT service provision, and deserved the same

importance as the other processes already mentioned. Hence the “Service

Support” process group was added and the support processes were added

within this group, drawing heavily on ITIL.

These changes resulted in the model shown in Figure 62.


QUT Page 159

Figure 62: Reference Model showing "Customer" object on right

6.4 Select Low-Level Process

After a first focus group and Delphi study that formed part of Craig Huxley’s

(Huxley 2003) work on identifying the processes that organisations should

focus improvement activities upon, the processes for modelling at the lower

level was selected. This selection was based partly on the results of the

focus group and Delphi study into the critical processes of an IT Service

Provider. The other consideration was the availability of material on the topic.

The topic chosen for modelling was Incident Management. Incident

Management is a relatively structured process. Structured processes are

more suited to the chosen modelling technique (Scheer 1998 p556).

Processes that are poorly structured may need alterations to the modelling

conventions or even the use of other modelling techniques.

6.5 Design and Validate the Low-Level Model

The steps of defining the design philosophy and identifying information

entities have already been discussed, leaving the steps of building and

validating the lower level models.

At the lower levels the ITIL books provided the most detailed guidance. None

of the other best practice frameworks had a similar low level advice on how

Users

Clients

Customer


QUT Page 160

to provide IT services. Hence, ITIL was the starting point for the models at

the lower level. ITIL is a natural language that contains graphic depictions, an

example is shown in Figure 63 (CCTA 2000 section 8.3)

Figure 63: Example of ITIL text and diagrams

These graphical representations are ad hoc in design and used through out

the mostly text explanation. Often there is no real link between the text and

the models, for example not all the objects in the graphics are explained in

the text, none of the connections, or symbols are explained etc.

The conversion from textual descriptions into the semi-formal language of

eEPC involves a degree of interpretation. Considerable time was spent

reading and understanding the various parts of the ITIL chapters firstly to

gain an understanding of the material then to determine how the content

should be depicted. An initial eEPC was designed showing the end-to-end

Incident management process and then presented to the next focus group.

An example of the type of change made to the model included the Incident

logging. The focus group members agreed that all calls to the Service Desk

should be recorded in the Service Desk software, instead of only Incidents

requiring resolution as was depicted in the model.


QUT Page 161

Feedback from the focus group was that the models were too detailed to

provide an overview about the process. In particular the inclusion of the trivial

events was seen as unnecessary duplication. The focus group members

indicated that, while the detailed depiction should not be lost, the model

needed an intermediate layer that could communicated the end to end

process in a few simple steps.

With this feedback, a second model was produced using the value-chain

technique. The level of detail of this value chain was guided by one of the

internal models provided to the research team by one of the focus group

participants. The purpose of this internal model was slightly different to the

ITSP reference model in that it was designed for use with clients, so it

concentrated on highlighting the interactions with the client during the

process as opposed to providing guidance for internal use, so at some

stages the level of detail in the company specific model was excluded in the

value chain developed for the reference model. This combined with a

graphical model from ITIL formed the basis of the level 1 value chain for

Incident Management.

Although ITIL formed the basis of the reference model, several parts of the

developed model were influenced by other sources. Two tangible and

specific examples of this are the use of application supported service

requests and the use of “whiteboards”. The application support for Incident

logging came from the SAP Solution Manager. The Solution Manager

interfaced to a user-transparent interface built into the application (in this

case R/3) which allowed the user to submit an Incident report from within the

application. This use of application driven Incident logging and submission is

also seen today in Microsoft’s “Office” package. Essentially, by submitting a

help request or event record through the functionality supported from within

an application, important information can be automatically captured to help

classify, diagnose and resolve the Incident. For example, by using the

reporting functionality that is interfaced with SAP R/3, the transaction code,

license, release, database version, module etc. as well as the user ID can all

be gathered automatically by the system, with the user adding any free text

comments and then submitting the Incident to the Service Desk, without


QUT Page 162

leaving the application,. This type of “smart reporting” can automate the

some of the steps of Incident management.

The “whiteboard” concept comes from reviewing the documentation of the

REALTECH Helpdesk software. ITIL suggests that every Incident that has

been reported should be acted upon to find a resolution and restore services.

The helpdesk software from REALTECH realises that many Incidents may be

reported that apparently have the same root cause, and that resolving the

cause will restore all the services about which the Incidents have been

reported. The most commonly cited example is multiple reports of email not

working, suggesting that the email server is down. Resolving a single

Incident by restoring the email server will resolve all of the email related

Incidents. In large support and service centres hundreds of calls could be

received about such an Incident, it would not be efficient to investigate and

attempt a resolution for each of these calls. The “whiteboard” concept by

REALTECH allows Incidents to be attached to one another, effectively the

newly related Incident is parked while the original report is investigated and

resolved, which may either restore the services for the new call, or provide a

work-around which can be implemented (but not investigated) many times.

These are two examples of non-ITIL concepts that were included in the

models.


QUT Page 163

Chapter 7: Reference Model Testing

7.1 Introduction

This chapter describes the reference model testing, of both the high level and

lower level models. The testing is an important step in the design of a

reference model, as it ensures that the reference model is of sufficient

semantic and pragmatic quality.

The semantic quality assurance is performed by checking that the processes

contained within it can handle common real life situations that, for whatever

reason, were not apparent during the build and validate steps.

The pragmatic quality is tested by allowing those not involved with the

development of the model the opportunity to use the reference model and

make comments or changes. Examining how the model was used can also

provide information about whether the model was interpreted to mean what it

was intended to mean.

The high level model was tested and improved through use in Craig Huxley’s

work (Huxley 2003), using the Level 0 model as a reference model for the

process identification in order to test the developed process targeting method

based.

Because of the nature of the testing and the amount of description, the

reference model testing has been structured into its own chapter.

The lower level models (levels 1 and 2) were tested and improved through 2

case studies, where the reference model developed in Chapter 6 was used

for business process re-engineering projects.

Both of these testing scenarios are described here.

7.2 Test High-Level

The high level model was used as a process identification tool for the

process targeting phase by Craig Huxley, a member of the research team for

the parent research project. This constituted the testing phase for the high-


QUT Page 164

level model. As discussed in Chapter 6 the high level model was designed

and validated using focus groups. Huxley’s work involved case studies were

imbedded in action learning cycles with different companies involved with

each of these cycles (Huxley 2003).

For the purposes of this study only the initial stages of the Huxley’s case

studies are relevant. The first stages mainly the “Define Scope” in step 2 of

Huxley’s ten steps, is relevant because this is were the reference model was

applied.

The process targeting methodology’s ten steps, which was the output of

Huxley’s work, are shown in Figure 64 and are related to the BPM Lifecycle.

Figure 64: Rosemann’s BPM Lifecycle relationship to Huxley's Target methodology

Huxley’s case studies worked through the 10 steps of the targeting

methodology and the reference model was used in the second step. The

Process Targeting

Processindentification

AS-IS Modelling

Analysis

TO-BE Modelling


Process Execution

Monitoring/Control

1: Pre Planning

2: Define Scope

3: Assess Dependency

4: Assess Failure rate

5: Develop BSC

6: Assess Impact

7: Calculate Criticality

8: Assess Cost/Benefit

9: Prob. of Success

10: Select Process


QUT Page 165

reference models were then customised to suit the organisation involved and

formed the list of processes from which one or several would be selected.

Three case studies were conducted, however only two of the case studies

used the reference model for the scoping and identification step. The third

case study organisation had already developed a high level list of processes

and therefore did not need a process identification step.

The model was presented on A3 paper in the early stages of the case

studies, and participants (representatives from the organisations involved)

were invited to re-use as much of the model as they felt relevant and

appropriate. The reference model presented to the first organisation is

presented in Figure 65.

Figure 65: High Level model used for first case study (Core processes only)

Consistent with the action research approach used by Huxley, some of the

changes in the first case study were carried over into the second case study.

This included the reference model changes made in the first action research

cycle; hence the second case study used the reference model including the

modifications made in the first case study.

Also, as mentioned in the previous chapter, due to time and resource

constraints the changes to the high level model were not re-validated.


QUT Page 166

At a higher level the notion of “best practice” loses some significance,

because it is mostly about the “what” and it is very difficult to convey the

“how” at this high-level. Therefore the main objective of the testing phase for

the high level is to ensure adequate coverage of the processes an IT Service

Provider undertakes.

7.2.1 Case Study Design

Selection of Participants

Participants were invited from those already involved with the research, that

is, large IT services outsourcing vendors.

Participants for the two case studies were sourced from the focus group

participants or invitees. There was a preference for case study sites with

headquarters located in the city of the research team, though interstate

centres were also considered. Each participant in the focus group and Delphi

study approached regarding their interest in participating in the case study

research.

Two national companies agreed to participate in the case study phase. All

were focused on outsourced services in the IT service delivery industry with

two from the commercial arena and one a government owned commercial

entity with customers from both government and public organisations.

(REALTECH AG, CSC and Citec)

Data Collection

The primary source of data was the modified reference models that were

produced during the process identification activities and the description of the

changes that have been documented in Huxley’s Master’s Thesis (Huxley

2003).

Data Analysis

The modified models were compared to the original high level model.

Differences between the models and the reference model were identified.

Also the pre-existing list was compared to the original reference model. The

differences recorded were the number modifications the existing model,


QUT Page 167

addition of parts of the model, deletion of parts of the model and the degree

of structural changes to the model.

The number of changes was assessed by to recorders, the author and

Dr Christian Probst from the University of Muenster. Dr Probst is experienced

in both process modelling and the domain of IT service provision. The degree

of structural changes to the model was assessed in a subjective manner, with

three degrees of changes, minor, moderate and extensive. The models were

rated individually and then the differences in opinions were discussed and a

concessus reached.

7.2.2 Case Study Results

Case Study 1

The organisation involved with this case study was also involved in the

generation of the high level model through the focus group. The model that

was used for the list of processes is presented in Figure 66, the new

processes have been circled.

Figure 66: Enterprise specific model of first case study

There are 4 additional processes and the layout and structure of the

reference model was modified. “Define Billing” and “Define Reporting” were


QUT Page 168

added to the model to complete the Service Definition processes. The

addition of the “Quality Processes” indicated the need to have operational

quality assurance processes and “Enhancement Management” was added

which was described as the processes that took place that were aimed at

fitting the services offered by the provider to the needs of the consumer.

A structural change was to re-define the scope of “Service Delivery” to

include the older service delivery processes as well as the service support

processes. The reasoning behind this change is that the “service” offered to

the customer consisted of both the old service “delivery” and the service

“support”. The change also provided a neat separation between the back-

office “Service Infrastructure” which was generally a common platform from

which multiple customers were serviced and the customer-specific service

delivery.

A subtle change is the replacement of the arrows with the rectangles. The

case study participants thought the arrows confused the model.

This raises an interesting situation for the derivation of the model, where

single process definitions for the infrastructure backend could be combined

with multiple instances of customer specific processes for the Service

Delivery which could be different for each customer. Such tailoring of front

end processes to individual customers would only make business sense if

the customers were important enough to warrant a custom solution. It has

been noted that these front end processes could be matched to different

service level types (e.g. gold, silver, bronze). It is also conceivable that back-

end infrastructure processes could be individualised per customer or service

level type.

Case Study 2

The modified reference model was presented to the second case study

consistent with the action research methodology employed by Huxley. Two

processes were added to the high-level model, the “Proactive Management”

and the “Site Visit Management”.


QUT Page 169

Figure 67: Enterprise Specific Model for Case study 2

The “Proactive Management” was similar to the “Enhancement Process” in

that it was aimed at bringing new ideas and solutions to the attention of the

customer.

“Site Visit Management” was an acknowledgement that service providers,

may need to maintain and manage on-site resources such as a local Service

Desk.

Also the Change, Enhancement and Release Management processes were

extended into the CRM space to show that these processes should be

closely linked to the customer facing processes.

Another change was the renaming of the Service Delivery to “Remote

Support Services”, which reflected the company specific situation.

One of the perceived shortfalls in the original reference model was the lack of

detailed descriptions and definitions of the processes, which corresponds to

the quality factor of having a defined language and scope

Site visit Management

Service Definition

Define Service ScopeDefine Service Levels

Define Billing

Define Reporting

Service Infrastructure (Hosting)

H/WMgmt

S/WMgmt

AppMgmt

Security/Continuity Mgmt

Service Delivery

Monitor Service Levels

Manage Capacity

Configuration

QA

Qua

lity

Proc

esse

s

Customer Relationship ManagementBilling

Reporting

Rel

ease

Mgm

t

Prob

lem

Mgm

t

Cha

nge

Mgm

t

Inci

dent

Mgm

t

Hel

p de

skM

gmt

Service Support

Enha

ncem

ent

Mgm

t

Proactive Mgmt

Remote Support Services

Site visit Management

Service Definition

Define Service ScopeDefine Service Levels

Define Billing

Define Reporting

Service Infrastructure (Hosting)

H/WMgmt

S/WMgmt

AppMgmt


H/WMgmt

S/WMgmt

AppMgmt


Service Delivery

Monitor Service Levels

Manage Capacity

Configuration

QA

Qua

lity

Proc

esse

s

Customer Relationship ManagementBilling

Reporting

Rel

ease

Mgm

t

Prob

lem

Mgm

t

Cha

nge

Mgm

t

Inci

dent

Mgm

t

Hel

p de

skM

gmt

Service Support

Enha

ncem

ent

Mgm

t

Proactive Mgmt

Remote Support Services


QUT Page 170

Results summary

In Table 25 is a summary of the background of the 2 models and the number

and types of differences between the models and the original reference

model.

The table shows whether the reference model was used to develop the

enterprise specific model, whether the organisation involved in the case

study was directly involved in the creation of the reference model, and the

number of changes to the models. The final column shows the degree of

structural change to the model, which captures changes to the layout of the

model.

Model Model Background Changes

Used RM Involved with dev.

# Name changes

# Additions # Deletions Structural

changes Modified Model 1 Y Y 0 4 0 minor

Modified Model 2 Y N 1 6 0 minor

Table 25: Summary of Differences to Reference Model

7.2.3 Limitations and Conclusions

There were several limitations in this phase of the research. Firstly, as

explained in Chapter 6 the changes to the model were not re-validated

through focus groups. Hence the decisions on which were incorporated into

the final model (discussed below) were left entirely to the research team.

A second limitation is that the case studies were designed to test Craig

Huxley’s targeting methodology, not specifically to collect data about

changes to the reference model and hence the model was not used for any

further steps in the Business Process lifecycle.

The third limitation was the use of action research, as the output from the first

was used as input to the second case study. Although this is a strength of the

research, which allowed the refinement of the targeting process, having two

independently modified reference models may have given an interesting

comparison and a more valid insight into which of the changes were

organisation specific and which were needed to improve the reference

model.


QUT Page 171

Another limitation was the buy-in of the organisations. It was clear that the

participant organisations were not attempting to embark on a whole-scale

business process re-engineering effort, the result being that insufficient time

and resources were expended on modifying the high level model thoroughly.

The final limitation is that the changes to the reference model were not

facilitated by an expert, although this may not be a limitation as such,

because the model may eventually be used by non-experts.

The case that had an existing process framework raises an interesting

question in regard to the relationship between process management maturity

in an organisation versus their need for a reference model or need for a

specific type of reference model, and how existing models can be used in

conjunction with reference models. It could be argued that an organisation

with a mature process framework and definitions would not benefit from a

reference model as much as an organisation without a mature enterprise

model. It would certainly be true that the reference model’s application as a

template would be limited, but the other uses for a reference model could still

make it useful to an organisation. One of the most interesting uses for a

reference model in a mature organisation would be the semantic mappings

between the internal processes and that of the reference model. This

semantic mapping could help to communication to other organisations that

would obviously not be using exactly the same models and constructs as one

another. This could help create a common terminology within an industry, as

is the intent with models such as eTOM.

As explained in Chapter 2 it is unreasonable to assume that a reference

model can be used without some degree of customisation. With this in mind,

providing the appropriate reference model was selected for the situation, the

reference model quality for a specific domain could be partly inferred from the

number of changes to the model. This mirrors the “economic efficiency” of

use discussed in Chapter 4, in that a model is high in quality if it is efficient to

use. One of the costs of a model is the required changes to instantise the

model, consuming time and resources.


QUT Page 172

Hence, it is reasonable to conclude that, all other factors being equal, the

fewer changes are needed the higher the model quality. The testing phase is

used to determine the quality of the model and to identify any changes

needed to improve the quality. If there are no changes to the model during

the testing phase then it can be assumed that the model is of reasonable

quality particularly with respect to the economic efficiency of use. From the

results shown above, the models seem to have been reasonably well suited

for the case study organisations with only limited changes, and no deletions.

While conducting the second part of the testing phase, i.e. to increasing the

quality of the model, a distinction needs to be drawn between which of the

changes made during the case studies were enterprise specific, i.e. were

customisations of the reference model during derivation, and which changes

were deficiencies in the original reference model. The deciding factor

governing this decision is whether the changes to the reference models

explained above would improve the reference model as a tool for business

process re-engineering. The following changes were made to the original

model as result of the high level testing. This decision was made by the

coders (Taylor and Probst) based on their knowledge of the specific

situations, the domain in general and using input from other information

entities to judge the generalisability of the enterprise model depictions.

7.2.4 Effect on Reference Model

As a result of the testing phase using the case studies conducted by Huxley

in the Process Identification and Targeting Phases, the following changes

were made to the model.

The “Billing Definition” and “Reporting Definition” were added to the model.


QUT Page 173

Figure 68: Level 0 Processes

The names were changed to align them with the naming conventions and the

Service Desk Management was removed because it wasn’t perceived to be a

real process but rather more of an organisational unit, which was responsible

for some of the processes in Figure 68.

7.3 Test Low-Level 7

The testing of the lower level models was conducted through two case

studies, where the models were provided to consultancy teams engaged with

business process improvement projects with two organisations.

Again the case studies had two purposes, to determine the extent of re-use

of the models, and to improve the models based on the enterprise models

developed and feedback from the model users.

Both of the case studies were in the Incident Management / service desk

domain. Both projects used the business process management lifecycle. The

7 Parts of this chapter section is published at the RefMod2003 Conference in Frankfurt in September 2003, in the paper Taylor and Probst “Business Process Reference Model Languages: Experiences from BPI Projects”.

Service Levels Definition

Reporting Definition

Har

dwar

e M

anag

emen

t

Sof

twar

e M

anag

emen

t

Appl

icat

ion

Man

agem

ent

Security & Continuity Management

Billing Definition

Service Levels Monitoring

Configuration Management

Capacity Management

Service Scope Definition

Rel

ease

Man

agem

ent

Enha

ncem

ent

Man

agem

ent

Billing

Reporting

Site M’ment

Prob

lem

M

’men

t

Inci

dent

M’m

ent

SERVICE DEFINITION

INFRASTRUCTURE SERVICE DELIVERY CUSTOMER RELATIONSHIP

SERVICE SUPPORT


QUT Page 174

first focused on the AS-IS modelling and the process analysis, while the

second project, performed the AS-IS modelling, analysis and produced a TO-

BE model.

7.3.1 Case Study Design

In this phase of the testing the value chain and eEPCs were used in two

Business Process Improvement projects. The main objective of these case

studies was to find situations in the enterprise models to improve the

reference model. These improvements could be semantic, pragmatic or

syntactic improvements.

These projects were conducted with industry partners in collaboration with

the Queensland University of Technology. In the first half of 2003 these

projects were conducted in the area of IT Service Support specifically

Incident Management. The BPI methodology used was that of the Business

Process Lifecycle (Rosemann 2000), which includes the steps Process

Identification, AS-IS Modelling, AS-IS Analysis, TO-BE Modelling, Process

Implementation, Process Execution and Process Monitoring as discussed in

Chapter 2. Postgraduate IT student teams were given 13 weeks to suggest

improvements to the processes effectively reaching the end of the TO-BE

modelling activity.

The history of these collaborative projects and a description of the general

educational aims of the projects can be found in Rosemann et al. (2000).

Students were given access to both the ITIL books (Service Delivery and

Service Support) and the developed reference model in ARIS (which was

provided as web pages), and were encouraged to examine both sources as a

basis for their domain knowledge. Unfortunately, due to discrepancies in the

versions of ARIS available to the students and the author, the models could

not be delivered for direct editing but only displayed on the web pages (i.e.

the model Ability to Edit was locked).

The pairing of the ITIL books and the models was seen by the research team

as an efficient way of providing a formal well defined and consistent model,


QUT Page 175

and the extended content (e.g. glossaries, extended explanations), provided

by the books, that was demonstrated as so important in Chapter 4.

The students were advised to use the sources as they saw appropriate. That

is, they were made aware of the resources, but their use was not mandatory

nor linked to their marks for the subject.

The aim of the case studies was to examine actual help and Service Desks

to help improve the reference model. In this improvement process three

steps were used which are described in more detail in the data analysis

section using a Best Practice by Composition Design principal as discussed

in Chapter 5.

Selection of Participants

The student teams were selected from high achieving post-graduate students

with a high pass in the pre-requisite subject introducing process modelling

and process improvements.

The industry partners were selected based upon suitability to the reference

model, i.e. they were providing IT services. Both organisations were selected

because of the excellent working relationship between the CITI and the

organisation, as well as previous co-operative research efforts. CITEC was

selected because they provide IT services as an outsourcing partner. Pauls

was selected to provide some insight as to how well the reference model

could be applied to an internal service provider, which is closely related to the

target domain of the reference model (i.e. IT services as an outsourcing

arrangement). Applying the reference model outside its specific domain can

offer interesting comparisons.

Presented in next are brief descriptions of the two case study organisations

and their service support environments.

CITEC

Case study one was conducted with one of the focus group member

organisations, CITEC. CITEC is an external IT services provider with several

Service Desks dispersed geographically and logically. For the project the


QUT Page 176

student team investigated two of the Service Desks. One was seen as the

internal benchmark, while the other was a high volume Service Desk. Due to

resource constraints only the AS-IS processes models were completed.

CITEC’s services include infrastructure management, applications

management, information brokerage, business process outsourcing and

associated professional services. Their Service Desk software was Quantam.

PAULS

Pauls, a member of the Parmalat group, runs IT as an internal service. It also

however fields calls from external retailing customers who use their system to

place orders. Help desk which services approximately 600 calls per week

and is in operation 24x7. The IT environment of Pauls has 650 users over 35

sites via LAN/WAN. Pauls has been using the Quetzal 1.03 Help Desk

package for handling calls and support jobs.

Data Collection

There were two sources of data collected about the use of the reference

models in the projects. The most important was the finished enterprise

specific models of the teams, in both the AS-IS and TO-BE scenario (Pauls

team only). The project teams used ARIS as their modelling tool and the final

models for the different scenarios were the primarily source of data for the

testing phase. The data collect was the final databases from the project

teams, which contained the models in the ARIS toolset.

The second source of data was through surveys of the model users (the

students). The surveys were aimed at examining the students’ opinion of the

reference model in relation to the ITIL books and consisted of several open

ended questions. These surveys were also followed by informal discussions

with the students about their experiences using the reference model. Data

about the use, perceived quality and consistency of both the books and the

models was collected from the project team members via surveys. Questions

focused on drawing comparisons between the original ITIL books (books)

and the ARIS models (models). After preliminary demographic information on

modelling and domain background, the respondents were asked to identify


QUT Page 177

how both the models and books were used in the project (e.g. for process

identification, AS-IS modelling template etc.). The survey went on to ask for

possible improvements in both the books and models in free text questions

and finished with a direct comparison between the models and the books on

a five point scale in relation to given statements (e.g. contained more

ambiguities, limited creativity etc.). The topics of these comparisons were

drawn in part from (Schütte 1998) work identifying the impact of reference

model use and partly on the quality attributes described in Chapter 4. The

survey questions are contained in Appendix C.

Data Analysis of Models

The analysis of the models was conducted in two phases.

The first phase looked at the general similarity of the enterprise specific

models to the original reference model. The second phase examined specific

differences and whether these could be used to improve the reference

model.

First Phase – Degree of Re-use

This phase of the analysis was aimed at determining how much of the

models had been re-used. The first phase of the data analysis was aimed at

determining how much of the models had been re-used for the enterprise

models. The aspects considered in the comparison of the models were the

semantics, objects, naming, branching points, layout, hierarchies and

interactions to other processes.

Two coders examined the reference model and then the enterprise specific

models and rated the degree of agreement on a simple three point scale

(high, medium and low). The reason that these ratings were used is that they

give simple to code and simple to interpret results. Attempts were made to

introduce a more detailed coding scheme, but the analysis was prohibitively

time consuming, often very difficult and did not add any useful data.

A high degree of re-use means that the enterprise model was obviously

based on the reference model, and had a high similarity of semantics and


QUT Page 178

syntactic constructs, as a general rule about 70% of the models concepts

appear to be drawn from the reference model.

A medium level of re-use means that, although it is apparent that certain

parts of the model are the same as the reference model, the reference model

has been reasonably changed. As a simple rule around 30-70% of the

concepts of the model are drawn from the reference model.

A low level of re-use means that, most of the model appears to have been

built from scratch or changed beyond recognition from the reference model.

Less than 30% of the model is based on the reference model.

Specific examples of the models classified in three levels of re-use are

contained in Appendix B.

Second Phase – Improvements to the Reference Model

This phase of the analysis was aimed at improving the reference model.

Following on from the first stage, individual differences were identified. After

this identification each change, or related group of changes, was examined to

determine whether the enterprise specific model contained a generalisable

concept, in other words, whether the change was not a result of the

derivation of the model (e.g. changing “Incident record” to “work request”).

If the differences were not a result of derivation, the changes were examined

to see whether they offered higher syntactic, pragmatic or semantic quality to

the reference model. This decision was made by the coders based on their

knowledge of the specific situations, the domain in general and using input

from other information entities to judge the generalisability of the enterprise

model depictions.

There are 4 ways these differences could impact on the reference model if

they were determined to be relevant.

Firstly, the enterprise specific model contained paths or objects that should

be added to the reference model, for example to cover a situation not already

in the reference model. If this was the case then these new semantic

elements were added to the reference model, which are mostly situations


QUT Page 179

that were not conceived of during the reference model design. This situation

is termed an addition.

Secondly, if the enterprise specific model excluded something that was

present in the reference model and it was determined that it should not be in

the reference model it was deleted. In this case a scenario that was included

in the reference model would never, or only very rarely, happen. This

situation is termed “exclusion”.

Thirdly the semantics may be neither of the two first, where the enterprise

model simply depicts a different way of handling the situation. This is termed

a “modification”. The modifications were seen as semantic improvements to

the reference model based on the enterprise model. Essentially, it meant that

the solution depicted in the enterprise model was better practice than that

depicted in the reference model, as judged by the two coders.

Fourthly, the enterprise specific model had a better pragmatic or syntactic

method of depicting the same semantics. In this case, the content of the

model is essentially the same, although the way of depicting it is different.

For example, a particular modelling object or construct that was confusing or

un-necessary. This situation is termed a “pragmatic change”.

Differences that did not fit one of these categories were ignored as not

relevant, for one of 3 reasons. Either they were a result of the derivation

process that was not deemed to be generalisable, they did not add to the

reference model which is aimed at depicting best practice (for example

manual processes for which there are currently available automated support)

or thirdly they were perceived as modelling errors.

Coding

Due to the subjective nature of both of these phases, two independent

codings were conducted on the data, one by the author and the other by a

coder (Dr Christian Probst) with a high domain and modelling knowledge and

experience. Both coders were closely involved in the projects and understood

the domain, the specifics of the organisations involved and of process


QUT Page 180

modelling. After the codings any differences in the results were discussed

and an agreement was reached.

Data Analysis of Survey

The data collected via the surveys was simply averaged (for the Likert Scale

questions), while the responses to the open questions and the informal

discussions are used to provide some context to the other results.

7.3.2 Case Study Results

The case study results are presented in this section. Firstly, the results of the

analysis of the models are presented, followed by the results from the survey.

Results from Analysis of Models

The first phase analysis is presented per model to highlight the differences in

the degree of re-use in each model. In the second phase, the improvements

phase, results is presented per case study, because it is not important from

which models the improvements were derived.

Case 1 – CITEC

Phase One – Degree of Re-use

The AS-IS CITEC value chain followed the reference model exactly. This

provided a convenient unit of analysis for the comparison, i.e. the models for

each step of the process.

VAC Detect Incident

Record Incident

Assess Incident

Resolve Incident

Close Incident

AS-IS model 1 High Medium Medium Medium Low Medium

AS-IS model 2 High Medium Medium Medium Low Medium

Table 26: Re-Use of models in the CITEC case study

Using the data analysis steps outline in the data analysis section above, the

following changes to the reference model were made.

Phase Two – Improvements to the Reference Model

This section explains the improvements made to the reference model based

on the CITEC enterprise specific model. The type and source model of the

improvements are indicated in brackets.


QUT Page 181

Event Logging (Modification - Both)

The enterprise model showed that not all of the errors recorded in a typical

event log generated by a monitoring system should be regarded as Incidents

or be forwarded to the Service Desk. This would often overwhelm a Service

Desk with many trivial and quite regular and normal events. The reference

model was changed to show that only events that the monitoring systems

had classified as Incidents would be forwarded to the Service Desk.

In one of the models the Line of Service staff are able to manually log an

Incident, without going through the Service Desk. Because this would

improve the response times, as well as the classification accuracy this was

also included in the model. The consequences of this choice are discussed in

Chapter 8 in further detail.

Incident Reporters (Addition – AS-IS 1)

It was noted that not only could a user report an Incident but also one of the

provider staff or a third party could also report the Incident. The effect on the

model was to include this in the description of the organisational unit type

“Reporter”.

Using Event Diagrams (Pragmatic Change - Both)

In the original reference model event diagrams were used. These were

removed in the enterprise model, because they added extra complexity to the

model. The information contained in the event diagrams was simply

transferred to the eEPC. In the reference model they were also removed.

Assessment of the Incident (Pragmatic Change - Both)

The enterprise model showed some of the functions originally in the Assess

Incident in Record Incident. The student team misunderstood the Assess

Incident to mean “find the work around for the Incident”. The Assess Incident

step is very important as it is within this step that the prioritisation and

categorisation take place. To emphasise the importance of the assessment

step and distinguish it from the Develop New Resolution step the VAC, both

steps were explicitly expressed in the value chain.


QUT Page 182

Scope of Incident Management (Addition - Both)

The models contained all types of incoming contact with the Service Desk,

even contact that was not to report an Incident. For example, the model

showed how enquiries were processed.

The effect on the models was to show the grouping of the events in the

Assess Incident step, into the different event types, one of which is Incident.

After this the guidance from ITIL can be used to deal with the Incident.

Expanding the scope of the process effectively reuses the start of the

Incident Management process to also deal with the non-Incident events (e.g.

an enquiry for a phone number, an update on some information received by

the Service Desk). This is also a logical step because the same software and

resources could effectively be used to log events as it could to manage

Incidents.

Automatic Escalation Due to Severity (Addition - Both)

The enterprise models showed that once an Incident had been assessed it

could trigger a hierarchical escalation process if the Incident had been

assessed as having a high level of severity.

Taking this idea further, an integrated and sophisticated Service Desk tool

could track automatically trigger escalations (either hierarchical or to Problem

Management) if a particular set of conditions had been met. Examples of the

conditions that could trigger the hierarchical escalation include the level of

impact of an Incident or the combined level of impact multiple linked

Incidents. Conditions that could trigger the Problem Management process

include the combined impact of the number of Incidents attached to a

Problem record or the impact of a particular Incident (or linked group of

Incidents) that should trigger the Problem Management process to create a

new Problem record, or the combined impact of Incidents linked to a

particular Known Error, that may require the economic efficiency of the

resolution of that Known Error to be re-assessed.

Re-assignment during Restoration (Addition - Both)


QUT Page 183

During the restoration process (not just the diagnosis step) the Incident may

need to be re-assigned, if the resolution was traced to another line of service.

The summary of the types of improvements derived and which model/s they

came from is shown in Table 27.

Additions Exclusions Modifications Pragmatic Changes

AS-IS Model 1 1 0 0 0 AS-IS Model 2 0 0 0 0

Both 3 0 1 2 Table 27: Summary of Improvements derived from CITEC Models

Case 2 – Pauls’ Models

Phase One – Degree of Re-use

The AS-IS CITEC value chain followed the reference model exactly. This

provided a convenient unit of analysis for the comparison, i.e. the models for

each step of the process.

VAC Detect Incident

Record Incident

Assess Incident

Resolve Incident

Close Incident

AS-IS model High Low Low Low Low Low

TO-BE Model High Medium Med Low Low Low

Table 28: Re-Use of models in the Pauls case study

The Pauls models had very low re-use of the reference model, particularly

the AS-IS model. An interesting aspect of this case study was the increased

re-use in the TO-BE model, where 3 out of 5 value chain steps increased in

the level of re-use. Even in the Resolve Incident step, although both models

were rated low, there was more re-use in the TO-BE model.

Phase Two – Improvements to the reference model

Only one difference in the Pauls’ models was incorporated in to the reference

model.

Reporter Interaction (Addition - Both)

One of the models from the Pauls processes specifically showed the client

interaction at the Resolve Incident step. The inclusion of the client

interactions in the reference model was added textually in the attributes of


QUT Page 184

the steps in which major interactions with the user or reporter would normally

take place if needed on an ad hoc basis. That is in the Assess Incident and

Develop New Resolution.

Additions Exclusions Modifications Pragmatic Changes

AS-IS 0 0 0 0 TO-BE 0 0 0 0 Both 1 0 0 0

Table 29: Summary of Improvements derived from Pauls Models

Summary of Survey Results

Five individuals from the student teams who were involved with the projects

responded to the surveys. The CITEC team had only 2 members and the

Pauls team had 5 members. The full survey results can be found in the

Appendix D. Presented here is a summary of the results.

The most interesting finding from the survey was the total number of uses for

the books versus the models. Each respondent was asked for how they used

the models and the books. The models were reportedly used in twice as

many times than the books (18 reports in comparison to 9). However, this

was not reflected in the response to the direct comparison, “Which did you

use most?” in which the response favoured of the books. Reasons for this

could include that the books took longer to understand, or that the models

were used as an introduction to the domain and then the books were

consulted for further detail.

Models were also perceived as easier to read and as providing a better

overview than the books and as allowing better semantic quality of the

models produced during the projects (i.e. TO-BE and AS-IS). The models

allowed better opportunity to check the syntactic quality of the models

produced in the projects by providing an example for comparison. There was

a positive reaction to the models compared with the books when asked which

source contained ideas that could most easily be incorporated into the TO-

BE models.

Sample results are provided in Table 30 (see Appendix D for full details of all

the questions plus standard deviations). These results are those that had an


QUT Page 185

average response of more than greater than 4 or less than 2 (i.e. 1 away

from the mid-point of 3) and hence represent the strong views of the

respondents collectively.

Question Average Rating Actual Value

Books (1) (5) Model

Which gave the best overview? x 4.0

Which one was easier to understand? x 4.2

Which allowed semantic errors to be detected

in the AS-IS models? x 4.0

Which allowed syntactic errors to be detected

in the AS-IS models. x 4.0

Ideas from which material can be easily

incorporated into the TO-BE? x 4.2

Table 30: Sample Results from Survey questions

In the open questions, all respondents confirmed the models added value to

the books, and all indicated that in a future project they would use both the

books and the models.

Overall the results from the survey indicated that the students perceived the

models as at least as useful as the books. Assuming that the books are of a

certain quality, which can be judged by their acceptance in industry, then it

can be interpreted that the models are also of a certain quality for these

projects.

7.3.3 Limitations and Conclusions

The major limitation of the case studies was the subjective nature of the

decisions about what aspects of the enterprise specific models should

influence the reference model. However, using two coders, both with

advanced knowledge of the modelling technique, tool, general and specific

domains, mitigates this limitation.

The other major limitation is the external validity of the findings. The testing

phase could benefit from several more case studies, and more surveys of the

reference model users, especially in different sites which have identified as

being “best practice”, which could challenge the ideas put forward in the


QUT Page 186

reference model, to improve the reference model, and also offer more input

as to the amount of re-use that could be expected using the reference model

for BPM.

Perhaps one of the most severe limitations is the use of students to conduct

the “consultancy engagements”. The students lacked extensive experience in

process modelling and had little to no previous exposure to the domain as

indicated by the responses to the demographic questions about previous

modelling experience and domain experience. This limitation was mitigated

by several factors, including the education provided for the students before

the projects were conducted as well as the coaching by several individuals

experienced in the domain and these types of business process

management projects.

The final limitation noted is the disjoint between the purpose of the model and

the application of the model. Although the model depicts “best practice”, it

was used mainly for capturing the AS-IS states of the processes. It was not

used for a TO-BE model for the first case and the production of a TO-BE

process model for the second case was not the focus of that project (the

focus was instead to determine an appropriate IT solution), and hence didn’t

receive the attention and effort that it could have. Also the reference model

processes rely heavily on an integrated and sophisticated IT support

application suite, the implementation of which was not within the scope of the

projects, hence many of the processes depicted could not be exactly copied

into the TO-BE models.

The above limitations should be considered when interpreting the

conclusions from the case study which is presented next. The conclusions

are structured around the two stages of models produced in the case studies,

the AS-IS and TO-BE models and the impact of the reference model on

these models is discussed.


QUT Page 187

AS-IS Modelling

The results show that the model was re-used more in the AS-IS CITEC case

than the AS-IS Pauls case. This could be an indication of the difference in

sophistication between the IT provision processes of the two organisations.

The particular circumstances of the IT service provider may not necessitate a

high level of measurable and repeatable service, especially in the internal

provider case. This could make some of the processes in the reference

model redundant. For example, there may be no check to see whether calls

are covered by a service level agreement. The “best practice” processes may

be very different to the current processes of IT service management

processes in an organisation, making the reference model only of limited use

for the AS-IS modelling for certain organisations, particularly less mature IT

service providers.

In both cases however the re-use of the model was generally low. This could

be due to one or more of the following reasons.

In Chapter 4, the ability to use the model efficiently was identified as a quality

criterion for reference models. Having a locked reference model means that

the model cannot be edited directly, and hence its application (and therefore

degree of re-use) may be limited. When asked what aspects of the reference

model could be improved, the students asked that it be an “open” (i.e. not

locked) model, that they could edit directly.

Another reason is the current maturity and sophistication of the Incident

Management processes at the organisations.

The third reason is that the models may have been perceived as not useful

for the purposes of the projects. The results from the survey questions,

especially about intention to use in future indicate that the students did

perceive the models as useful.

TO-BE Modelling

The Pauls models showed more re-use in the TO-BE models as compared to

the AS-IS models, and even though some of the individual ratings may not


QUT Page 188

have changed, after discussion both coders agreed that in all steps more of

the reference model had been re-used. Despite this increase in re-use much

of the model was not applied. This could be due to several reasons.

In the TO-BE modelling for simple or internal IT service provision

environment, the reference model may not be widely re-useable because it

does not reflect the desired state of this particular IT service provider. In

other words, the model has been built to deal with a complex IT service

provision domain, with possible multiple clients with different SLA, large

numbers of Incidents, many staff, many products and complex support

requirements, which may not be the case, especially as an internal service

provider.

Another reason is that it may be prohibitively expensive to implement the

reference model, meaning that short or even medium term process goals of

the organisation may differ from the reference model.

7.4 Chapter Summary

This chapter covered the testing of the reference model in process

identification and targeting then separately in business process management

projects. Among the major outcomes were the following points:

• The model had a high degree of re-use at the high-level

• The model had only a medium level of re-use in the BPM projects for

the AS-IS modelling for the external IT service provider

• The model had a low level of re-use in the internal service provider

• The model was perceived by the student teams as being useful

• Reasons for the lower level of reuse (as perceived by the researcher)

o Application to a slightly different domain (i.e. internal IT service

provision in the Pauls case)

o Lack of maturity of the organisational processes


QUT Page 189

Chapter 8: ITSP Reference Model Outputs

8.1 Introduction

The previous chapters outlined the procedure used to design and then test

the reference model. This chapter summarises the outputs of that procedure.

It looks at the outputs of the procedure both in terms of the actual process

models that were developed, and ideas contained therein, and in the lessons

learnt about the procedure of designing reference models using the methods

discussed in the previous chapters.

The reference model itself is contained in an ARIS database.

8.2 Model Outputs

8.2.1 Level 0 Model – Business Process Framework

The entry point to the more detailed levels of the model is the business

process framework, which is Level 0 of the model. The naming of the levels

has been based on the conventions used in SCOR and eTOM, with the

highest levels of abstraction, being denoted as the lowest numbered level.

Therefore the level number gives an indication of the scope of the processes

and the level of detail.

This is the highest abstraction of the model and presents core 19 processes

grouped into 5 areas as shown in Figure 69.


QUT Page 190

Figure 69: Process Groupings of the ITSP Reference Model

These groupings, while actually being the highest level of the model, are so

abstract that they are not given the Level 0 designation, rather the individual

processes as shown in Figure 70 form the Level 0 processes. Note that as

discussed in Chapter 2 and Chapter 6, only the core processes have been

further developed.

SERVICE DEFINITION

INFRASTRUCTURE MANAGEMENT

CUSTOMER RELATIONSHIP MANAGEMENT

SERVICE SUPPORT

SERVICE DELIVERY

ENABLERS

STRATEGY


QUT Page 191

Figure 70: Level 0 Processes of the ITSP Reference Model

The processes identified in the high level model are shown in Figure 70 and

are explained below. As stated earlier, ITIL had a large influence on these

definitions and the structure of the reference model.

Hardware Management

Hardware Management is the process of installing, maintaining, upgrading,

the physical infrastructure, including any networks used to deliver the

application on the client or provider side, but excluding the intermediate

network if any, such as that provided by a third party telecommunications

provider. The management of such a relationship with a telecommunications

provider is covered in the Enablers processes. It may include desktop

support but this is not essential.

Software Management

Software Management is the process of maintaining the IT systems that

support the delivered application, such as the database management

software, operating system or any other software that provides the platform

for, or supports, the delivered application or services.

Service Level Definition


Har

dwar

e M

anag

emen

t

Sof

twar

e M

anag

emen

t

Appl

icat

ion

Man

agem

ent


Billing Definition



Capacity Management


Rel

ease

Man

agem

ent

Ser

vice

Enh

ance

men

t

Billing

Reporting

Site M’ment

Prob

lem

M

’men

t

Inci

dent

M’m

ent

SERVICE DEFINITION

INFRASTRUCTURE SERVICE DELIVERY

Cha

nge

Man

agem

ent

SERVICE SUPPORT

CUSTOMER RELATIONSHIP MANAGEMENT


QUT Page 192

Application Management

Application Management deals with the processes specific to the delivered

application. It involves the maintenance of the application, the technical

changes to the application or functional changes to the system.


Security & Continuity Management is the process that manages the risk to

the ITSP infrastructure. It involves such aspects as physical and logical

security, failure plans and contingency plans and is aimed at providing and

then executing plans for methods of providing the IT service, if the ITSP

infrastructure is impacted on by an event that reduces its ability to provide

services. Examples of such events include natural disasters, acts of terrorism

etc.

Service Level Monitoring

Service Level Monitoring is the process of collecting and analysing the

metrics needed to demonstrate the service provider’s fulfilment of service

level agreements.

Capacity Management

Capacity management involves all the activities that are aimed at matching

the current and future capabilities of the IT resources (both technical and

human) to cost effectively meet the demands placed upon it. This includes

understanding the current and predicting the future demands and managing

consumer demands. This process plays an important role in investigating the

cost effectiveness of investments in infrastructure, especially in the longer

term.


Configuration Management deals with ensuring that all the items that make

up the IT infrastructure are described and the details and relationships

between them are maintained in a database. Items should include software,

hardware and any documentation associated with these items. The

definitions of processes, service level agreements, software licenses etc.

should be maintained by Configuration Management.


QUT Page 193

Release Management

Release Management involves all the processes from having an approved

change to the monitoring of the release in the live environment. The release,

or rollout, could be of a new or modified software or hardware component.

The process is focused on protecting the live IT environment and ensuring

that the release is checked and monitored before and after implementation.

Change Management

Change Management involves the changing from one state to another of the

IT infrastructure. It involves the necessary checks and approvals to ensure

that any changes made to the infrastructure, are introduced in a controlled

and documented manner and that these changes bring about their expected

benefits to the service.

Service Enhancement

Enhancement management encompasses the ITIL process of Change

Management as well as other activities. The extra activities include

identifying, investigating and possibly preparing a business case for the

opportunities to supplement existing services, effectively placing a more pro-

active role on the generation of change requests.

Discussions since the process has been renamed and increased in the scope

(from Change management to Enhancement management) indicate that this

is an extremely important area for IT service delivery. It allows the provider to

on-sell or leverage current investments and also the client to benefit from the

experience and expertise of the provider, by identifying new opportunities for

IT in the client enterprise. One of the aims of this process should be to

ensure that the IT service is maximally effective (not only efficient) for the

client and that new capabilities that can be cost justified (either to a particular

client or to the provider organisation itself) are implemented.

The Enhancement Management process deals with ITIL’s Change Requests

as well as Service Requests. This process should investigate the operational

impacts of any proposed change.


QUT Page 194

Client Site Management

An important distinction between the in-house provider and the outsourced

provider is the management of on-site premises. This process captures all

the client site management, such as liaising with clients affected by any

changes, regular updates and meeting to discuss operational and strategic

matters with individual clients. It also includes arranging for incident

resolutions where onsite work is needed, scheduled outages, release

timelines etc. and works closely with Release management.

Billing

The process of billing is extremely important to the IT service provider,

particularly the outsourced provider, but also, in the case of internal cost

accounting or cost recovery, for an internal service provider. It involves the

collection of the data required to produce the invoice, the furnishing the

invoice to the client and dealing with payment and billing enquiries.

Reporting

This process involves gathering all the data and presenting it to the client. As

discussed in the focus groups this process is very important and should be

used as a feedback session from the clients to ensure that the service level

agreements are meeting the business needs of the client. It would interact

with the Service Definition processes and the Enhancement processes.

Problem Management

Problem Management deals with the correction of underlying causes of

Incidents. The problem management process involves preventative

measures as well as analysis of data in order to prioritise and resolve

problems and errors in the IT Infrastructure to ensure smooth future

operation. As well as this pro-active element, Problem management can be

triggered from other processes such as Incident Management.

Incident Management

The main objective of Incident Management is to restore the services as

soon as possible after they fall below agreed service levels. This process

spans the process from event detection through to the closure of an Incident


QUT Page 195

record. It also includes all the processes for initial contact with the Service

Desk (including Incident, service requests, enquiries etc.).

Incident Management also handles all of the incoming contact to the Service

Desk.

8.2.2 Level 1 Model: Incident Management – VAC

The Incident Management process also handles all the incoming contact with

the Service Desk, such as non-Incident reports or enquiries. From the ITSP’s

viewpoint the purpose of the Incident Management process is to restore

services (or provide acceptable alternatives), when the level of IT service

provided by the ITSP does not meet the SLAs.

The secondary purpose of the Incident Management process is to provide a

single point of contact for all incoming interaction with the ITSP’s customers.

From the client’s perspective the major outcome of the Incident Management

process provided by the ITSP is to enable the client’s users to continue work,

and provide all the information associated with the services offered by the

ITSP covered by SLA.

The Incident Management value chain is made up of 6 steps. They outline

the end to end process for managing incidents, from the time when they are

detected to when the incident record is closed.

Figure 71: Level 2 Value Added Chain for Incident Management

In the next section each of the steps of the Incident Management process are

described.

1.1 DetectEvent

1.2 RecordEvent

1.3 AssessIncident

1.6 CloseIncident

1.4 Developnew

Resolution

1.5 RestoreServices


QUT Page 196

8.2.3 Level 2 Models

Detect Incident

The main purpose of this step in the Incident Management process is to

make the ITSP, specifically the Service Desk, who should have access to all

current or potential service outages, aware of the situation where a service

level is not being met, or a situation which might lead to a service level

breach.

Record Incident

The purpose of this step is to capture all the details of the Incident. It is

extremely important to ensure sufficient and accurate information, as this

information is used throughout the rest of the Incident Management

processes, as well as in many other processes, especially Reporting, Billing

and Problem Management.

Assess Incident

This step is one of the most important in the process. The purpose of this

stage is to classify the incident and match it to existing knowledge and

information. Both the classification and matching are extremely important.

Accurate classification is essential to determine the related service level

agreement/s, and to provide a basis for prioritisation and matching to existing

knowledge. The matching is one of the value-add steps for the ITSP.

The richness and completeness of the knowledge of the ITSP and the

effectiveness and efficiency of the re-use of the knowledge are essential to

the ITSP. This knowledge and ways of using it is one of the methods by

which the ITSP is able to provide services to customers at reduced cost

compared to internal service providers. Re-using existing resolutions,

contained in other Incident records, problem records or information supplied

by third-parties, removes the need to develop new resolutions.

Develop New Resolution

The purpose of this step is to create new information regarding how to

restore services. As a service provider builds its knowledge the need for this


QUT Page 197

step should be reduced. This step involves diagnosis and other tasks

requiring highly skilled personnel, meaning that it can be quite costly.

Restore Services

The purpose of this step is to apply the resolution, identified through the

Assess Incident step or recently created in the Develop New Resolution step.

The activities in this step may be extremely varied, as simple as advising the

client to use another printer, to a complicated fix to hardware, hence it is only

modelled very generically.

Close Incident

The Close Incident step is crucial as it ensures the accuracy of the initial

assessment, and that the client perceives that the services have been

restored to agreed service levels.

Assumptions

Although the purpose of the model was to depict best practice, several

instances occur where the definition “best practice” is in a general sense was

extremely difficult. Several assumptions and arbitrary choices were made

during the course of the design of the model.

Depending on the exact situation and factors such as pricing models for

support (e.g. flat fee, or per call basis), organisational culture or the

relationship between the client and provider, different solutions can be

perceived as “best practice”. This section describes the choices made in the

reference model, and the reasons they were selected. In doing so, alternate

methods of implementation are also described, although these were not

modelled in the reference model. They could be as variants. The reason they

were not modelled, however, was due to the time and resource constraints.

The choices made, their potential justification and other options for

implementation are described here.

Underlying Data Integrity

It is assumed in the model that all the underlying data that is used (e.g. the

user contact details, configuration items, service levels etc.) are correct. It is


QUT Page 198

conceivable that confirmation of these details is made part of the Incident

Management process, although assuming that the other processes are

running well (particularly Change and Configuration management) these

checks have been excluded from the model.

Incident Logging

With advances in technology, particularly with the internet, service desk tools

can be opened to clients. The decision to open the logging tool and the

extent to which clients can record and assess their own incidents is a matter

that should be determined in relation to other issues, especially the

consequences of inaccurate recording and assessment.

For example, allowing clients to determine the impact and severity of

incidents may lead to many incidents being prioritised as very important,

negating the usefulness of such a prioritisation structure, or service level

agreements bound to certain priorities.

The advantages of allowing users to log their own incidents are the reduction

of service desk time spent on logging and integration to self service IT

support functions.

Self Service

Some IT support tools, e.g. theGuard! Helpdesk from REALTECH, currently

support a self-service IT support using knowledge bases and search engines,

or context sensitive queries.

The implementation of this option would be attractive for flat-fee pricing

agreement structure arrangement. However, as mentioned in the ITIL

documents allowing or encouraging users to solve their own IT problems can

be counter-productive (CCTA 2000 Section 4.1.7). If users attempt their own

solutions they may complicate the situation. Even if they are successful it

may be less efficient for users, who are not experts and without tools and

training, to be fixing IT failures.


QUT Page 199

Also if the pricing model was a fee per Incident or time based model then the

implementation of a self service solution would probably be a sub-optimal

business decision.

Hence the implementation of self service is not depicted in the model.

Incident Acceptance

Events that are failures in the IT infrastructure but degrade (or could

foreseeably degrade) services covered by the SLA are not classified as

Incidents for the reference model. By only classifying the events that are

covered by an SLA, the provider is focused exclusively on the agreed service

levels. An accurate alignment of the SLA’s to the business needs is essential

for this assumption to work. The alternative is to classify all failures as

Incidents.

Incident Assessment and Closure

Some IT monitoring packages, e.g. theGuard! Application Manager from

REALTECH, can automatically detect and resolve certain Incidents. While

the appropriate utilisation of such systems is obviously best practice, ITIL

offers conflicting advice on how these automated processes should be

integrated with the other processes, particularly Incident Management. The

major discrepancy is in relation to the assessment and closure of these

Incidents and closure of any associated Incident records.

The “Service Desk” chapter of ITIL suggests that Incidents detected in the

infrastructure should be automatically routed to the appropriate person and

the Service Desk only notified of the Incident when an escalation point is

reached (CCTA 2000 Section 4.1.15). However, the Incident Management

chapter implies that all Incidents should be assessed by the Service Desk

(i.e. classified, linked to a service level agreement, prioritised etc.). These

steps would be missing in the case where the Incident is automatically

routed. Even if the assessment steps were performed, either automatically or

by the infrastructure team, the assessment would most likely not be

consistent with those being made by the Service Desk personnel.


QUT Page 200

The decision was made that all Incidents should be classified or at least

checked (using some default values attached to common automatically

initiated Incidents) by human operators of the Service Desk. The closure of

the Incident was also left in the hands of a human operator to ensure that the

Incident has been resolved satisfactorily.

Scope of Incident Management Best practice, as derived from discussions in the focus group, is that all

contact with the Service Desk should be recorded. This allows better

monitoring and control of the Service Desk, and provides data facilitating pro-

active measures to improve the efficiency or effectiveness of the service

provision.

In order to achieve maximum reuse of the models and the resources used to

support the implemented processes, the reference model has extended the

scope of Incident Management to include all contact with the Service Desk,

not just the process from the identification of an event as an Incident.

The models were extended to show the complete end-to-end process of the

detection of a service degradation (or upcoming degradation) to the closure

of the Incident record.

Definition of Incident

ITIL defines an Incident as:

“any event which is not part of the standard operation of a service and which

causes, or may cause, an interruption to, or a reduction in, the quality of that

service.” (CCTA 2000 Section 5.2)

where the “service” here is defined by the SLA’s for the particular customer.

One type of Incident is the “Service Request” which is defined as “every

Incident not being a failure in the IT Infrastructure” and gives an example as

“request for information/advice/documentation” (CCTA 2000 Section 5.2).

Service requests could therefore include requests for services not covered by

a service level agreement.


QUT Page 201

For the model, an event (i.e. any contact with the Service Desk) that is

received at the Service Desk is classified into Incident (as defined by the

definition in ITIL), service request or information request, as separate entities.

This definition is not a trivial matter because some of the major key

performance indicators for IT service provision revolve around Incidents.

Service Level Agreements (SLAs) are often linked to Incident numbers,

recovery times and statuses, and, particularly in an outsourcing arrangement,

these metrics can directly effect monetary payments and continued contracts.

Using an example discussed at the focus groups; defining whether a phone

call to the Service Desk asking for a telephone number is an Incident or not

can affect the relationship with the client. For example, by having a broad

definition of Incident, the number of Incidents in a given time period will be

higher. The number of Incidents is often a key performance indicator to which

financial incentives may be linked. This could be particularly important when

benchmarking within the industry.

8.2.4 Model Output Summary

As discussed in Chapter 2, the desired characteristics of the ITSP BP

reference model are as described in Table 31.


QUT Page 202













Table 31: Characteristics of an IT Service Provision BP Reference Model

Indicates partially completed

The actual model produced did not provide Intermediate and Task level

models for all the processes (only for Incident Management), but did provide

the entire Complete level model. This could allow further work to progress

using the same framework relatively easily.

The model was based on the ITIL framework. Many of the level 1 processes

were drawn directly from the ITIL processes, however Billing was drawn from

the eTOM framework. ITIL’s Change Management process was expanded

upon using feedback from the focus groups and case studies. The structure

and layout of the level 0 and 1 views were based around the concepts in the

eTOM high level models.

The Intermediate level processes (Level 2 - VAC) were derived from the ITIL

Incident Management chapter along with feedback from the focus groups.


QUT Page 203

Another important influence was an enterprise specific model supplied to the

researchers by one of the focus group members.

The Task level models, level 3, were again derived mainly from ITIL however,

they make several assumptions as outlined above. Many of the items have a

description which is derived or extended from the ITIL documents. Other

influences at this level include the enterprise specific model provided by the

focus group member, and software documentation and demonstration,

particularly the SAP Solution Manager, and theGuard! Helpdesk application.

The model provided some guidance in the runtime (as descriptions of the

objects in the model) and the Model Explanation has been explained in the

modelling conventions in this thesis. Several of the ITIL books, particularly

“Planning to Implement Service Management” (CCTA 2002), could be used

to provide the extended content in the Implementation and Run-Time areas.

8.3 Methodological Outputs

This section examines the perceived efficiency and effectiveness of the use

of the reference model design procedure. It examines what went well, what

didn’t and most importantly the lessons learned about the design of a

business process reference model.

8.3.1 Use of Focus Groups

This subsection examines the use of focus groups for reference model

design, looking at what worked well, and provides suggestions for future work

in using focus groups for reference model design.

High Level Modelling

The focus groups worked well for the higher level models. This could be due

to the higher level of participants (middle management) who had a good

overview of the operational aspects of their organisations. Due to its highly

generic level, there is little room to suggest best practice and the

development of the model was relatively straight forward.


QUT Page 204

Best Practice Thinking

Difficulties were encountered at the lower levels. At this level of detail

participants found it difficult to, in the words of Frank, “transcend their

subjective preferences and attitudes” (Frank 1999 p. 697). The purpose of

producing best practice, i.e. no constraints thinking, may not have been clear

to the participants, or the participants were not able to take this ‘green-field’

approach. A sense of defensiveness may have been felt by the participants.

This may have occurred because they were in front of their industry peers

and ultimately their competitors in some instances. The opinion of the

research team is that the participants were not consciously trying to defend

their positions; however this seemed to influence their thinking. Suggestions

for improvement would be to spend more time setting the directions and

perspective of thinking.

A major limitation on the ideas that generated from the focus group were the

constraints on the IT systems supporting the Incident management in

particular.

Discussing Detail

Problems were also encountered when modelling the detailed level

processes. This could be due to the lack of focus by middle management on

the detail of the processes. Participants at a lower level, for example Service

Desk staff or supervisors, could have been more helpful in the area of

Incident management because their sole responsibility lies in this area, as

opposed to the management level whose focus is spread across the

operations of the organisation.

Suggestions for improvements include inviting lower level employees who

would have an intimate knowledge of the problems and possible solutions

and improvements in the process that could contribute to the development of

best practice at this level. Because they may not be responsible for the

design of the process, only its execution, they may also view the process

more objectively. Another advantage is that those who execute the process

may be more able to ignore the implementation costs of best practice than

middle management. Ignoring the implementation costs and focusing on the


QUT Page 205

end state of best practice may make the focus group more creative and

appreciative of new ideas.

Attendance

Focus group attendance was a problem. Sometimes, of the 6 or 7 confirmed

attendants, as few as 4 actually attended. This was due largely to the time

constraints on the participants. Thought was given to individual sessions but

that negates the advantages of the focus group which include the discussion

between the participants which supposedly provides value to a reference

model.

One suggestion for improving the attendance is to invite more people than

needed (e.g. if aiming for 10 participants aim for 14 confirmations).

Domain Vocabulary

One of the more difficult aspects of managing the focus groups was the use

of domain specific vocabulary. Kitzinger when discussing focus groups

mentions that the research method is useful because participants can

discuss the topic “in their own vocabulary” (Kitzinger 1995 p300). Often the

participants used different vocabulary when discussing the topics.

In future a session could be run specifically on the vocabulary to be used for

the focus group, or information and definitions could be sent to the focus

group members before the focus group. Alternatively the focus group

moderator could spend time with the audience members individually before

the focus group and during the focus group act as an interpreter between the

organisations.

The other option is to develop a glossary of terms when problems are

encountered, although this may distract the focus group.

8.3.2 Bottom-up versus Top-down

The modelling was conducted in a top down approach. The Level 0 is more

generic so it is difficult to engender any ‘best-practice’ ideas into the model.

Also at this level it was relatively easy to reach agreement on the model.

When the level 2 models were constructed however, they sometimes didn’t fit


QUT Page 206

neatly into the higher levels. When this was the case, changes were made to

the level 1 model.

It is thought a combination of the top down approach and bottom up, with

validation and modification using the lower level of detail would be the best

approach for this purpose.

8.3.3 Modelling of Process Alternatives

During the model design, the determination of the “best practice” was made

difficult due to the varying circumstances with which organisations are faced

and the environment in which they operated (specific examples of which

were provided in Chapter 7). Because the scope of the modelling was

reduced, this research didn’t question certain aspects of IT service provision.

For instance, this research didn’t look at whether it was best practice to

charge per instance, per hour or flat fee for service support. At first, the

decision about billing models does not appear important in the scope of the

designed low level model (i.e. Incident Management) until one considers the

“best practice” examples described in Chapter 7, for example the

implementation of self service.

Self-service should cut the number of calls to the Service Desk, reducing the

service provider’s costs. This can increase profits in a flat fee service

provision environment but could lower them in a per usage or per hour

charging model. Essentially, the decision about the validity of self service as

“best practice” IT support is dependent on the choices made about the best

practice for billing models, at least in part.

Similar examples can be found throughout the models, where choices

depend on other choices made within the model, or even external to the

model, such as market demand or regulatory requirements. Some way of

depicting or at least capturing these dependencies would be advantageous.

A way of linking, and depicting this linking, of process models to different

choices made either in other parts of the model or external to the model is

needed. This complements the research underway by Rosemann (2002) on

the customisation of reference models.


QUT Page 207

Chapter 9: Summary and Outlook

9.1 Thesis Summary

This thesis has concentrated on two topics. Firstly, and most prominently,

was the area of reference models. The classification scheme, presented

again in Table 32, answered the first research question:

RQ2. What types of reference models exist?
















Available through

membership



Table 32: Reference Model Classification Characteristics

This classification scheme is based on previous classification schemes, from

enterprise models and reference models in particular. The scheme integrated

several of the previous schemes and extended them after reviewing several

reference models. It also provided explanations of each of the characteristics

and characteristic types.


QUT Page 208

Several models, related to the second topic IT service provision, were

discussed and classified using the scheme. The classification scheme

provided an overview of the types of reference models and also language

with which to discuss them. This language was then used to describe how

several different types of reference models can be applied in enterprise

modelling. After a general description, the application of reference models in

a particular context was described.

The next contribution was the answer to the third research question.

RQ3. How can business process reference models be used for process management?

The Business Process Management lifecycle was introduced to provide

specific examples of how and where business process reference models can

be applied and is summarised in Figure 72.

Figure 72: Business Process Lifecycle and related use of Reference Model









Process Execution




QUT Page 209

Chapter 3 introduced and justified the research methodologies being used in

the research, namely case studies and focus groups.

After identifying the gap in the literature regarding information on what

classifies quality in reference models, two case studies were performed,

aiming at defining, from a user perspective, the quality aspects of business

process reference models. The conclusions from that research not previously

mentioned in the literature or contradicted the literature are presented in

Figure 73.

Figure 73: Quality Conclusions that add to or differ from literature

This answered the second question;

RQ4. What characterises the quality of a business process reference models?

Chapter 5 defined several design philosophies that could be employed to

design reference models with specific characteristics. The philosophies are:

Blue Sky Design, Design by Abstraction, Design by Choice, Baseline Design,

Common Practice Design, Best Practice by Composition and Explicit

Alternatives Design. The advantages and disadvantages of each of these

philosophies were briefly discussed and the philosophies were integrated into

the reference model design procedural model. The procedural model is

shown again in Figure 74.

This chapter answered the question;

Syntactic Quality • Glossary • Simple

Semantic Quality • Scope and

limitations • Validation of

models • “Over-

completeness”

Pragmatic Quality • Application

documentation • Vendor training • Feedback

mechanisms

Economic Efficiency of Use


QUT Page 210

RQ5. How can a reference model be produced?

The design procedural model was then used to design a partial reference

model for IT service provision, particularly in Incident Management.


QUT Page 211

Figure 74: Proposed BP Reference Model Design Procedural Model

DesignHigh-Level

ValidateHigh-Level

TestHigh-Level

DesignLow-Level

ValidateLow-Level

SelectLow-Level

TestLow-Level

No changesmade

Low Level OK,RM finished

DefineReference

Model

Changesmade

Low Levelchanged

Low Level OK,RM notfinished

Reference Model to be

designed


QUT Page 212

Chapter 6 outlined the steps used to design the reference model, using the

procedural model as a basis, the high-level view of which is presented in

Figure 75.

Figure 75: Level 0 Processes of the ITSP Reference Model

Chapter 7 outlined the testing of the reference model, both at the high level,

using Huxley’s case studies, and then using the lower level reference model

in 2 business process management projects. The testing helped identify

areas that needed work in the model and also examined how much of the

model was re-used. Levels of re-use were generally low, although feedback

from the student participants indicated that they perceived the reference

models were useful. Several conclusions were put forward to explain this

apparent contradiction. One of the projects was with an internal service

provider, while the model was built for an outsourcing agreement, indicating

that the outsourcing processes may not suit an internal service provider. The

models provided to the consultancy team were “locked”. The final conclusion

on this issue is that the “best practice” depiction did not acknowledge the cost

of implementation of such practices, this may have reduced the desire to

implement such solutions, at least in the short to medium term, as depicted

by the TO-BE models.

Service Levels Definition


Har

dwar

e M

anag

emen

t

Sof

twar

e M

anag

emen

t

Appl

icat

ion

Man

agem

ent


Billing Definition



Capacity Management


Rel

ease

Man

agem

ent

Ser

vice

Enh

ance

men

t

Cha

nge

Man

agem

ent

Billing

Reporting

Site M’ment

Prob

lem

M

’men

t

Inci

dent

M’m

ent

SERVICE DEFINITION

INFRASTRUCTURE SERVICE DELIVERY CUSTOMER RELATIONSHIP

SERVICE SUPPORT


QUT Page 213

The design and testing of the reference model answered the question:

RQ1: What is an appropriate business process reference model for IT service provision?

The final stages of the thesis presented the research team’s view on the

lessons learnt from the process. The output from the procedure of designing

a reference model was discussed, as well as the procedure itself.

Fourteen high level processes were defined, and one of these processes was

described with lower level models, i.e. Incident Management. Several of the

process assumptions were outlined. The assumptions themselves as well as

their implications were discussed, in order to provide the reference model

user some awareness that in certain circumstances “best practice” was

highly dependant on other factors, both internal and external to the IT service

provider.

With the benefit of hindsight the use of a “Contains Variants” model, would

have been beneficial to capture the alternate perceptions of “best practice”

and the reasoning behind each perception. The acknowledgement that

different circumstances resulted in different “best practices” may have also

helped in the focus group setting, allowing differing points of view to be

acknowledged and captured for further analysis.

As well as the actual content of the models, lessons were learned about the

procedure of reference model design itself, particularly in relation to the use

of focus groups.

Suggestions that focus group moderators define the language for the focus

group and spend more time setting the perspective of the participants, i.e. to

rely on their experience but not be constrained by it, tighter moderation of the

focus groups, and the use of lower level participants were all put forward as

ways of improving the method.

9.2 Future Work

There are several avenues for future follow on work from this thesis.


QUT Page 214

From a general sense regarding the methodology of reference models, the

design philosophies could be further detailed, integrating methods of

comparison, combination and rating for information entities, and developing

modelling tools to support the reference model design procedure.

The reference model design procedure could be used to design reference

models in other domains.

Also methods could be found to combine common types of reference models,

for example process models with performance measurement models, or

extend the process view into other views including organisational and data.

Some work that is currently taking place using existing enterprise systems to

“re-document” models from actual activity e.g. IDS “Re-documentation Scout”

or the paper by Weijters and va der Aalst (2002), could be combined with

reference models, to automatically identify gaps between an organisation’s

actual processes and best or common practice processes. This could

provide industry benchmarking or standardisation data. If the reference

models had been integrated with a Maturity Model, then the maturity level of

an organisation’s processes could be automatically, or at least semi-

automatically, calculated. This could then form the basis of quality

accreditation (e.g. ISO9001), or assertion of compliance with other standards

(e.g. BS15000 the recent British standard for IT service management).

A major step forward for reference models would be the design of a

modelling language and tool support for the explicit alternatives type of

reference models which is the topic of research currently underway. Not only

should these explicit alternatives be able to be depicted and analysed in a

model, along with their inter-dependencies, but decision support tools could

be integrated to help those deriving the enterprise specific models chose

which alternatives were appropriate for the situation. Information including

case studies, success stories, associated vendor support tools or consulting,

cost benefit analysis templates, critical success factors could all be linked to

specific business questions, the answers to which could automatically

generate the enterprise specific model based on the reference model. In


QUT Page 215

effect this would create an upper-CASE tool, not for software, but for process

models, a CAME (Computer Aided Modelling Engineering).

For example, a question could be “would you like to implement a self service

tool?”. Provided with the question would be available industry solutions,

costs, benefits, case studies etc. By answering “yes” the model would

automatically add the self service processes to the enterprise specific model,

answer “no” would remove them. Interactions could also be mapped, the

information presented in the above could be different depending on the

answer to the question “would you like to bill on a per use, flat rate or per

hour basis?”. The answer to which would not only change the model but

influence the question and information of the self service question. Such a

model could also be used after implementation, as a scalable solution to

changes in business needs, by identifying how business decisions will/should

impact business processes (e.g. by changing the pricing model).

In the shorter term, the design of the ITSP reference model that has been

produced can be continued, adding the lower levels of detail to the other

processes, with further testing. Data, organisational and other views could be

added as well as an implementation guide or procedural model. To help with

the implementation, which for ITIL is often done a process at a time, an

“process interaction model” may be useful. This shows all the process

interactions that a single process has with the other processes. The data

dependencies could also be added. An example of such an interaction model

is shown in Figure 76.

For example in Figure 76, the main process being explored is centred. The

incoming and outgoing events, and the interfaces to the other processes, are

shown as connecting to this central process. This allows an easy reference to

highlight the interactions between the central process and other processes.


QUT Page 216

Figure 76: Example of possible Interaction Model

On a commercial level, reference models could be used for the design,

selection or evaluation of a IT service management software. This interest

was sparked by comments made during the focus group that a major

hindrance to the streamlining of IT service provision was the lack of

integrated IT support. A best practice solution will integrate IT support for the

process, in much the same way that the original BPR thinking was closely

linked to the introduction of integrated computing solutions in other areas of

business processes.

Within the model a distinction is made between manual (or semi-manual)

steps and automated steps, defining that best practice is as automated as

possible. Another model has been added to show how the business

processes could be used to derive data models, that would aid in software

development for the domain.

The body of the thesis concludes with these outlooks on possible future work.

Next are the references, followed by the appendices.

HardwareManagement

SoftwareManagement

ApplicationManagement

System erroralert

User detectsevent notin support

enabled application

User detectsevent in support

enabled application

MonitoringApplication

detects Incident

Event is ServiceRequest

EnhancementProblemManagement

Error causing Incidentcannot be identified

1. IncidentManagement

Enhancement ProblemManagement

Service RequestCompleted

Problemresolved

Incident Closed

Diagnosis found

needs updating


QUT Page 217

References Anonymous 1993. CIM-OSA: Open System Architecture for CIM, Springer, Berlin.

Anonymous 1998, AS/NZS 2777.1:1998, Information processing systems - Open Systems Interconnection - Basic reference model - The basic model Australian Standards.

Anonymous 2001, Technical Reference Model User Guide US Department of Defense. Location: http://trm.disa.mil/userguide_11apr01.pdf Assessed: 18/05/2002

Anonymous 2002, ASC X12 Reference Model for XML Design ANSI ASC X12C Communications and Controls Subcommittee, Data Interchange Standards Association, Inc. http:// www.x12.org/x12org/comments/ X12Reference_Model_For_XML_Design.pdf Assessed 19/07/2002

Anonymous 2003. AS/NZS 14143.4:2003 ISO/IEC TR 14143-4:2002 Australian/New Zealand Standard Information technology—Software measurement—Functional size measurement Part 4: Reference model.

Anonymous Year Unknown, SAP Help "R/3 Reference Model", SAP. Location: http://help.sap.com/sapdocu/core/470/helpdata/EN/35/28ea32e8aa5570e10000009b38f983/content.htm, Assessed: 14/05/2002.

Barry, P. 2002, 'How One.Tel fiddled the books', The Age, 9 April, pp.

Becker, J., M. Rosemann and C. v. Uthmann 2000, Guidelines of Business Process Modeling. Location: http://www.leonardo.com.au/library/Paper%20Becker%20Rosemann%20Uthmann.pdf, Assessed: 14/05/2002.

Bell, D. 1973. The Coming of Post-Industrial Society, Basic Books, New York.

Benbasat, I., D. K. Goldstein and M. Mead 1987, 'The Case Research Strategy in Studies of Information Systems', MIS Quarterly, vol. 11, no. 3, pp 18.

Bennett, C. and G. Timbrell 2000, 'Application Service Providers: Will They Succeed?' Information Systems Frontiers, vol. 2, no. 2, pp 195-211.

Benson, K. 2002, Australia IS Outsourcing Services - IS Outsourcing Competitive analysis IDC, 63.

Bernus 1998, GERAM : Generalised Enterprise Reference Architecture and Methodology IFIP-IFAC Task Force.

Bernus, P., K. Mertins and G. Schmidt, Eds. 1998. Handbook on Architectures of Information Systems. Berlin, Springer.

Biemans, F. 1990. Manufacturing Planning and Control: A reference model, Elsevier Science Publishers, Amsterdam.

Boyle, R. D. 2002, 'Doing business with an application service provider', Strategic Finance, vol. 83, no. 9, pp 24.

CCTA 2000. Service Support CD, The Stationary Office, London.

CCTA 2002. Planning To Implement Service Management, The Stationary Office, London.

Chin, D., K. Takea and I. Miyamoto 1989, 'Using Natural Language and Stereotypical Knowledge for Acquisition of Software Models', in K, Mayo (eds.), Proceedings of

http://help.sap.com/sapdocu/core/470/helpdata/EN/35/28ea32e8aa5570e10000009b38f983/content.htm

http://help.sap.com/sapdocu/core/470/helpdata/EN/35/28ea32e8aa5570e10000009b38f983/content.htm

http://www.leonardo.com.au/library/Paper Becker Rosemann Uthmann.pdf

http://www.leonardo.com.au/library/Paper Becker Rosemann Uthmann.pdf


QUT Page 218

IEEE International Workshop on Tools for Artificial Intelligence. Architectures, Languages and Algorithms., pp 290-295.

Curran, T., G. Keller and A. Ladd 1998. SAP R/3 Business Blueprint: Understanding the business process reference model, Prentice Hall, New Jersey.

Curran, T. and A. Ladd 2000. SAP R/3 Business Blueprint: Understanding enterprise supply change management, Prentice Hall, New Jersey.

Curtis, B., M. Kellner and J. Over 1992, 'Process Modeling', Communications of the ACM, vol. 35, no. 9, pp 75-90.

Davenport, T. 1993. Process Innovation: Reengineering work through information technology, Harvard Business School Press.

Davenport, T. and L. Prusak 1997. Information Ecology: Mastering the Information and Knowledge Environment, Oxford University Press, Boston.

Davis, R. 2001. Business Process Modelling with ARIS: A practical guide, Springer, London.

Drucker, P. F. 1990. The new realities : in government and politics - in economy and business - in society - and in world view, Mandarin Paperbacks, London.

Dubie, D. 2002, 'Reaping the rewards of best practices', Network World, vol. 19, no. 39, pp 10.

Duffy, T. 2001, 'Efficiency tool kit', Network World, vol. 18, no. 45, pp 56.

Dunn, P. 2001, 'ASPs: The lure of task outsourcing', Hospitals and Health Networks; Chicago, vol. 75, no. 8, pp 38-40.

Emam, K., J. Drouin and W. Melo, Eds. 1998. SPICE: The Theory and Practice of Software Process Improvement and Capability Determination. Washington, IEEE computer Society.

Fabbrini, F., M. Fusani, S. Gnesi and G. Lami 2000, 'Quality Evaluation of Software Requirements Specifications', in (eds.), Proceedings of 13th International Software Quality Week Conference, Software Research Institute, pp

Falkenberg, E. D., W. Hesse, P. Lindgreen, B. E. Nilsson, J. L. H. Oei, C. Rolland, R. K. Stamper, F. J. M. V. Assche, A. A. Verrijn-Stuart and K. Voss 1998, Framework of Information Systems Concepts IFIP.

Fern, E. F. 2001. Advanced focus Group research, SAGE Publications, Thousand Oaks, California.

Fettke, P. 2003. Personal Communication Reference model classification. Email. 2/04 To: C. Taylor.

Fettke, P. and P. Loos 2003, 'Classification of reference models: a methodology and its application', Information Systems and e-Business Management, vol. 1, no. 1, pp 35-53.

Fowler, M. 1997. Analysis Patterns - Conventions of Thought, Addison Wesley Longmann, Massachusetts.

Frank, U. 1999, 'Conceptual modelling as the core of the information systems discipline - perspectives and epistemological challenges', in Goodhue (eds.), Proceedings of Fifth Americas Conference on Information Systems, Milwaukee, pp


QUT Page 219

Gable, G. 1991. Consultant Engagement Success Factors: A case study and survey of factors affecting client Involvement in, and satisfaction with, consultant engagement in computer system selection projects, carried out for the Small Enterprises Computerisation Programme in Singapore, University of Bradford.

Gable, G., G. 1994, 'Integrating Case Study and Survey research methods: an example in Information Systems', European Foundation of Information Systems, vol. 3, no. 2, pp 112-126.

Garschhammer, M., H. Hauck, B. Hegering, I. Kempter, I. Radisic, H. Rolle, H. Schmidt, G. Hegering, M. Langer and M. Nerb 2001, 'Towards generic Service Management: Concepts A Service Model Based Approach', in (eds.), Procedings of Integrated Management, Washington, pp 301-4

Green, P. and M. Rosemann 2000, 'Integrated Process Modelling; An Ontological Evaluation', Information Systems, vol. 25, no. 2, pp 73-87.

Guldentops, E., J. Lainhart, E. Schuermans, J. Beveridge, M. Donahue, G. Hardy, R. Saull and M. Stanley 2000, Corbit 3rd Edition Control Objective Corbit Steering Committee and the IT Governance Institute.

Gulla, J. A. and T. Brasethvik 2000, 'On the Challenges of Business Modelling in Large-Scale Reengineering Projects', in K Smith (eds.), Proceedings of 4th International Conference on Requirements Engineering, pp 17-26.

Gupta, U. and G. A 1992, 'Outsourcing the IS Function: Is it Necessary for your organisation?' Information Systems Management, vol. 9, no. 3, pp 44-50.

Hammer, M. 1990, 'Reengineering Work: Don't Automate, Obliterate', Harvard Business Review, vol. 68, no. 4, pp 104.

Hammer, M. and C. Champy 1993. Reengineering the Corporation: A Manifesto for Business Revolution, Harper Business, New York.

Hars, A. 1993, Reference data models - Structure and application of libraries for semantic data models. Location: http://www-rcf.usc.edu/~hars/thesis_e.htm, Assessed: 13/05/2003.

Hay, D. C. 1996. Data Model Patterns - Conventions of Thought, Doreset House Publishing, New York.

Helbig, R. 1999, 'Process Management in the Agricultural Commodity Trade and Consequences on Vertical and Horizontal Co-operation', in K Hallow (eds.), Proceedings of 1999 World Food and Agribusiness Congress: Agribusiness Forum, Florence, Italy, International Food and Agribusiness Management Association, pp

Hollingsworth, D. 1995, The Workflow Reference Model, Workflow Management Coalition. Location: http://www.wfmc.org/standards/docs/tc003v11.pdf, Assessed: 30/4/2002.

Huxley, C. 2003. Implementing an Improved Method to Identify Critical Processes. Brisbane, Queensland University of Technology.

Ivancevich, J., P. Lorenzi, S. Skinner and P. Crosby 1997. Management: Quality and Competitiveness, Irwin/ McGram-Hill, Boston.

Kang, I.-S., J.-H. J. Bae and J.-H. Lee; 2002, 'Database semantics representation for natural language access', in (eds.), Proceedings of First International Symposium on Cyber Worlds, pp 127-133.

http://www-rcf.usc.edu/~hars/thesis_e.htm

http://www.wfmc.org/standards/docs/tc003v11.pdf


QUT Page 220

Kaplan, R. S. and D. P. Norton 1992, 'The Balanced Scorecard: Measures that Drive Performance', Harvard Business Review, vol. 70, no. 1, pp p9.

Kaplic, B. and P. Bernus 2001, 'Business Process Modelling in Industry: The powerful tool in enterprise management', Computers in Industry, vol. 47, no. 3, pp 299-318.

Kara, D. 2002, 'Lining up behind ITIL', Software Magazine, vol. 22, no. 1, pp 68.

Kitzinger, J. 1995, 'Qualitative Research: Introducing focus groups', British Medical Journal, vol., no. 311, pp 299-302.

Krogstie, J., O. I. Lindland and G. Sindre 1995, 'Defining Quality Aspects for Conceptual Models', in Unknown (eds.), Procedings of IFIP International Working Conference on Information Systems, Chapman and Hall, pp 216-231.

Lacity, M. and L. Willcocks 2000, Inside Information Technology Outsourcing: A state-of-the-Art Report Templeton Research.

Lavery, R. 2001, 'Does application hosting make sense for you?' Strategic Finance, vol. 83, no. 3, pp 44.

Lee, A. S. 1989, 'A Scientific Methodology for MIS Case Studies', MIS Quarterly, vol. 13, no. 1, pp 33-52.

Lindland, O. I., G. Sindre and A. Solvberg 1994, 'Understanding quality in conceptual modeling', IEEE Software, vol. 11, no. 2, pp 42-49.

Loos, P., O. Keitzel and A.-W. Scheer 1996, 'Adaptable Information Systems by Generic Structures', in G. Ernst (eds.), Proceedings of Sixth Workshop on Information Technologies and Systems - WITS'96, Cleveland, Ohio, pp 258-267.

Lowe, D. and R. Webby 1999, 'A Reference Model, and Modelling Guidelines for Hypermedia Development Processes', The New Review of Hypermedia and Multimedia, vol. 5, no., pp 133-150.

Malone, T., K. Crowston, J. Lee and B. Pentland 1999, 'Tools for inventing organizations: Toward a handbook or organizational processes', Management Science, vol. 43, no. 3, pp 425-443.

McGowan, C. L. and S. A. Bohner 1993, 'Model based process assessments', in Unknown (eds.), Proceedings of 15th International Conference on Software Engineering, pp 202-211.

Mertins, K. and P. Bernus 1998, 'Reference Models', in G. Schmidt (ed.), Handbook on Architectures of Information Systems. Springer-Verlag, Berlin, pp 615-617.

Merton R, F. M., Kendall P. 1956. The focused interview: a report of the bureau of applied social research., Columbia University, New York.

Miles, M., B., and A. Huberman, M. 1984. Qualitative data analysis: a source book of new methods, Sage publications.

Misic, V. B. and J. L. Zhao 2000, 'Evaluating the quality of reference models', in Unknown (eds.), Proceedings of 19th International Conference on Conceptual Modeling, Salt Lake City, Utah pp 484-498

Morgan, D. L. 1988. Focus Groups as Qualitative Research, SAGE Publications, Newbury Park, California.


QUT Page 221

Morin, R. M. 1999, 'British invasion: Will ITIL take hold in the U.S.?' Service News, vol. 19, no. 1, pp 21.

Myers, M. D. 1997, 'Qualitative Research in Information Systems', MIS Quarterly, vol. 21, no. 2, pp 241-242.

Niessink, F., V. Clerc and H. van Vliet 2002, The IT Service Capacity Maturity Model Software Engineering Research Centre.

O'Neill, J., B. B. Small and J. Strachan 1999, 'The Use of Focus groups within a Participatory Action Research Environment', in L. A. Suzuki (ed.), Using Qualitative Methods in Psychology. SAGE Publications, Thousand Oaks, California, pp 237.

Perdue, J. M. 2000, 'ASPs sink fangs into IT costs', Oil & Gas Investor, vol., no., pp 19.

Porter, M. 1980. Competitive strategy : techniques for analyzing industries and competitors, Free Press, New York.

Porter, M. E. 1985. Competitive Advantage, The Free Press, New York.

René Gaches Year Unknown, CimOsa Framework. Location: http://www.rgcp.com/cimosa.htm, Assessed: 5/5/2003.

Reyneri, C. 1999, 'Operational building blocks for business process modelling', Computers in Industry, vol. 40, no. 2-3, pp 115-123.

Rosemann, M. 1998, 'Managing the Complexity of Multi-perspective Information Models Using the Guidelines of Modelling', in Unknown (eds.), Proceedings of 3rd Australian Conference on Requirements Engineering, Deakin Australia, pp

Rosemann, M. 2000, 'Using Reference Models within the Enterprise Resource Planning Lifecycle.' Australian Accounting Review, vol. 10, no. 3, pp 19-30.

Rosemann, M. 2002, Process-oriented Administration of Enterprise Systems, Queensland University of Technology. Location: http://www.citi.qut.edu.au/research/ism/projects/admin_enterprise.jsp, Assessed: 05/02/2003.

Rosemann, M., I. Davies and P. Green 2003, 'The very model of modern BPM', Information Age Feb/March: pp.

Rosemann, M. and P. Green 2000, 'Integrating Multi-Perspectives into Ontologies.' in W. J. Orlikowski (eds.), Proceedings of 21st International Conference on Information Systems, Brisbane, pp

Rosemann, M., D. Sedera and W. Sedera 2000, 'Industry-oriented Education in Enterprise Systems', in G. Gable (eds.), Proceedings of 11th Australasian Conference on Information Systems, Brisbane, Vitale, pp CD-ROM.

Ross, J. W., M. R. Vitale and C. M. Beath 1999, 'The Untapped Potential of IT Chargeback', Management Information Systems Quarterly, vol. 23, no. 2, pp.

Ryoo, J., J. F. Stach and E. K. Park 1999, 'Extension and partitioning of use cases in support of formal object modeling', in Unknown (eds.), Proceedings of Application-Specific Systems and Software Engineering and Technology, pp 238-243.

Saulnier, C. 2000a, 'Groups as data collection method and data analysis technique: Multiple perspectives on urban social work education', Small Group Research, vol. 31, no. 5, pp 607-627.

http://www.rgcp.com/cimosa.htm

http://www.citi.qut.edu.au/research/ism/projects/admin_enterprise.jsp


QUT Page 222

Saulnier, C. F. 2000b, 'Groups as data collection method and data analysis technique: Multiple perspectives on urban social work education', Small Group Research, vol. 31, no. 5, pp 607-627.

Scheer, A. 1994. Business Process Engineering: Reference Models for Industrial Enterprises, Springer-Verlag, New York.

Scheer, A. 1998, 'ARIS', in G. Schmidt (ed.), Handbook on Architectures of Information Systems. Springer-Verlag, Berlin, pp 541-565.

Scheer, A. 1999. Business Process Frameworks, Springer-Verlag, Berlin.

Schütte, R. 1998. Grundsätze ordnungsmäßiger Referenzmodellierung, Gabler, Wiesbaden.

Seymour, L. A. and M. Edwards 2001, Customer Value Powers Opportunity for Network and Hosting Service Providers IDC White Paper Sponsored by IBM.

Silverston, L., W. H. Inmon and K. Graziano 1997. The Data Model Resource Book - A library of logical data models and data warehouse designs, John Wiley & Sons Inc., New York.

Sofaer, S., B. Kreling, E. Kenney, E. K. Swift and T. Dewart 2001, 'Family Members and Friends Who Help Beneficiaries Make Health Decisions', Health Care Financing Review; Washington, vol. 23, no. 1, pp 16.

Sriram, V. Year Unknown, Challenges in the Asian market. Location: http://www.infosys.com/investor/analystmeet2002/ppt/Challenges-in-the-asian-market.ppt, Assessed: 5/5/2003.

Stamper, R. K. 1992, 'Sings, Organisations, Norms and Information Systems', in Unknown (eds.), Proceedings of 3rd Australian Conference on Information Systems, Wollongong, pp 21-55

Swift, B. 2001, 'Making sense of application service providers, Part 1: Business computing comes full circle', Risk Management, vol. 48, no. 7, pp 21.

Tao, L. 2001, 'Shifting Paradigms with the Application Service Provider Model', Computer, vol. 34, no. 10, pp 32 - 39.

Taylor, F. W. 1911. The principles of scientific management, Harper & Bros., New York.

Tellis, W. 1997, 'Introduction to Case Study', The Qualitative Report, vol. 3, no. 2, pp.

Thorp, J. 1998. The Information Paradox. Realizing the Business Benefits of Information Technology, McGraw-Hill, New York.

Timbrell, G., N. M. Andrews and G. G. Gable 2001, 'Impediments to inter-firm transfer of best practice in an enterprise systems context', in Unknown (eds.), Proceedings of 7th Americas Conference on Information Systems, Boston, MA, pp 1084-1090.

van der Aalst, W. and A. Kumar 2001, 'A reference model for team-enabled workflow management systems', Data & Knowledge Engineering, vol. 38, no. 3, pp 335-363.

van der Aalst, W., A. H. M. ter Hofstede and M. Weske 2003, 'Business Process Management: A Survey', in M. Weske (eds.), Proceedings of International Conference on Business Process Management, Berlin, Springer-Verlag, pp 1-12.

Weijters, A. J. M. M. and W. M. P. van der Aalst 2002, 'Rediscovering Workflow Models from Event-Based Data.' in Unknown (eds.), Proceedings of Third International NAISO

http://www.infosys.com/investor/analystmeet2002/ppt/Challenges-in-the-asian-market.ppt

http://www.infosys.com/investor/analystmeet2002/ppt/Challenges-in-the-asian-market.ppt


QUT Page 223

Symposium on Engineering of Intelligent Systems (EIS 2002), Sliedrecht, The Netherlands, NAISO Academic Press, pp 65-65.

Willcocks, L., D. Feeny and G. Islei 1997. Managing IT as a Strategic Resource, McGraw-Hill, London.

Williams, M. R. 1997. A History of Computing Technology, IEEE Computer Society, Los Alamitos.

Yao, Y. and L. Murphy 2001, 'Client Relationship Development for Application Service Providers: A Research Model', in Unknown (eds.), Proceedings of Proceedings of the 35th Annual Hawaii International Conference on System Sciences (HICSS-35.02), Hawaii, Computer Society, pp 3006 -3015.

Yin, R. K. 1994. Case Study Research: design and methods, Sage Publications Inc, Thousand Oaks California.

Zachman, J. A. 1987, 'A Framework for Information Systems Architecture', IBM Systems Journal, vol. 26, no. 3, pp.

Zamperoni, A. and P. Lohr-Richter 1993, 'Enhancing the quality of conceptual database specifications through Validations', in B. Thaleim (eds.), Proceedings of 12th International conference on the Entity-Relationship Approach, Berline, Springer, pp 85-98.

Zimmerman, E. W. 2002, 'Application service providers: Are the risks worth the rewards?' AFP Exchange, vol. 22, no. 1, pp 38.

Zwegers, A. J. R. 1998. On Systems Architecting – a study in shop floor control to determine architecting concepts and principles. Eindhoven, Eindhoven University.


QUT Page 224

Appendices

Appendix A Quality Case Study Protocol

A study conducted by the Centre for Information Technology Innovation (CITI) QUT, Brisbane. Case Study protocol [design documentation and Investigators’ notes] Investigators

Chris Taylor Wasana Sedera CITI 2, George Street Brisbane QLD 4001 Tel 3864 9476 Fax 3864 1969 Email: [email protected]

School of Information Systems 2, George Street Brisbane QLD 4001 Tel 3864 1924 Fax 3864 1969 Email: [email protected]

Case study objectives To capture the ‘critical’ aspects that should exist in a good reference model To analyse the level of importance of these aspects To identify means of achieving these factors when applied in a real life context Case study design Broadly, the choice is between a single case study Vs a multiple case study approach. Both have there pros and cons, and issues that are specific to the context and resources of the study. We have selected a multiple case study approach. Unit of analysis Projects that use Reference process models Theoretical basis for Model Quality


QUT Page 225

(adapted from Quality of Model Framework, (Lindland et al. 1994)) This Quality model will be used to examine and categorise the types of factors of a model that are important when using a reference model for Business Process Modelling projects. It was adapted from Lindland’s quality of Models framework and is presented here as the theoretical basis for the measures of what makes a model useful, in order to derive the list of critical factors a model must possess to be useful in a BPM exercise. Of particular interest in this research will be the aspects that exist in, or around, the model that assist with driving the quality of the model. A collective term “support” will be used to capture these aspects. The Support aspects are analogous to Lindland et al’s “means”. The framework above was used to help create the questions, by providing a framework that prompted questions into each area and as a classification tool for the questions (and their responses). This paper is based around the hypothesis that not all the different types of quality are important in all cases. The study is to examine which aspects of quality are important when using a business process reference model for business process modelling. Sampling frame Sampling parameters Possible choices Actors Reference Model users

Sponsors of the initiative using the reference models Process owners (who may already have fallen into any of the above categories)

Mode Individual Interviews Email correspondence Observations

Limitations:

Model

Language Domain

Audience


QUT Page 226

Relying on respondent to separate perceptions from reality, esp wrt semantic vs pragmatic quality, e.g. if something was perceived as ‘wrong’ in the model was it a semantic issue (the model really is wrong) or a pragmatic issue (the model was interpreted incorrectly). “Reference models: critical success factors” Case study - Interview structure (Interview protocol) Compiled by Wasana Sedera and Chris Taylor State note of appreciation for time set aside for interview Get permission to use audio tape (if applicable)

1. Introduction 2. -State Overview 3. Study 4. Purpose of interview 5. Ethics 6. Context Information

Can you describe the overall goals of using <name of ref model> at <company name>? What motivated the organization to use <name of ref model>? Who was involved in making the decision and promoting the ref model? How did you learn about it? Is this a part of a larger initiative? Can you explain for what applications, you intended to use the ref models? How would you describe the overall approach you used to deploy the ref model at <X>? What were the main steps? (Please state and describe in detail) Ex: step 1: Project initiation - with users and modellers Training the modellers/users Etc.… How did you decide the scope of the project? How many models were developed overall (please specify, how many from each different level, if possible) Can we see some example models, please? Do you think that the scope of the project was realistically defined? Did you mange to finish this phase of the project in the estimated time frame? Did you develop models out side the initially specified domain? Were there any bottlenecks for resources? Where do you see further applications of <ref model name> at <X>? Have you done any formal ‘evaluation’ on this initiative? If yes, can you describe their evaluation process and the results of the procedure? Can you specify the benefits that <the ref model name> set forth for X, which would have otherwise been unattainable? Can you give an example, where <the ref model name> really helped? Do you believe that the organization has achieved the goals set forth for this project?


QUT Page 227

What lessons (possible weaknesses) have you learnt from this exercise? (In other words, what would you do differently, next time?) Any specific project management concerns/ issues? Any specific modelling concerns/ issues? Testing the a-priori model What were the “issues” for you to proceed? How did you overcome them? (Collecting the negative aspect – of existing issues) What facilitated the task? (Collecting the positive aspect – of existing issue) Was there any thing <critical> that had to be there first, for you to proceed with the next steps? Is there anything that you wish, you had <upfront> to do a better task? How do you think this would have assisted the mapping initiative? (Collecting the aspects that the informant, may not have quite experienced, but would have appreciated to have) Syntactic Quality How well did the models stick to the pre-defined rules between shapes of the language? How well did the models stick to the pre-defined symbols/terms of the language? Did the model use them consistently?8 Did the models fit together according the rules (inter model)? 9 Were there any aspects of the language that had no correspondence to the domain? Were there any aspects of the language that had multiple or unclear meanings? Was the appearance of the models consistent with each other? (i.e. layout, naming conventions)? Where the rules applied consistently throughout the model10? Syntactical Support: What did, or would, you do to ensure syntactical correctness of any additions/modifications? Was there anything in the model (symbols, rules) that were not defined or explained? Did the model present a meta model11? Was a meta-model developed?12

8 from Becker

9 Reason: look at systematic design (GoM) layering, linking etc.BUT the consistence between different models is viewed as a part of semantic quality (zamperoni, lohr-richter 1993) in Becker 2000

10 similar to GoMs guideline of comparibility, i.e. that the rules have been applied identically, e.g. layout rules or naming conventions

11 question drawn from Becker, GoPM, for evaluation of the syntactical correctness of a

model it is indispensable to have an explicit (doeucmented) meta model)

12 This will indicate the importance of having a meta model


QUT Page 228

Did the model provide help to ensure syntactical correctness on additions/modifications?13 What did you do to ensure syntactical correctness on additions/modifications? Did the model include any supplementary material (e.g. glossary, definitions)? Did you have a way of capturing information that was not supported by the language14? Did you use any other languages other than those used in the reference model? Semantic Quality How well did the model capture its area? Did the model cover all of its stated scope15? Were there many statements that were not relevant to you/the domain? Was there anything important/useful missing? Where there any errors in the model, i.e. things that would not be realistically possible? Was there anything in the model that you didn’t agree with? Were there many repetitions? Were there many trivial statements that were not beneficial? Where there many new ideas that would work well in real life (i.e. best practice)? Where there any contradictions in the model16? Semantic Support What did, or would, you do to ensure semantic correctness of any additions/modifications? Did you use any strategy to ensure semantic correctness on additions/modifications? Was any content fed back to the developers17? (have you got any examples?) One way to support Semantic quality is increasing Language-Domain fit: Were there any things that could not be properly shown in the model due to the modelling language? How did you handle this? Did you make any additions/changes to the symbols or rules18? (rules: within a model and across models) L-D Support Was the same model presented in different languages? Why was this done?

13 used to determine the need for a tool or a quality checklist for modified/created models

14 Both syntax and semantics

15 the scope determines the domain of the model

16 drawn from zamperoni 1993 “the first step to approach semantical correctness is to detect contradictions in the schema [i.e. model]

17 used to check the availability of a feedback mechanism for RM producers

18 could be both semantic and syntax


QUT Page 229

Were different languages used to model different things? (E.g. data model for data and process flows for process) Pragmatic Quality Could the stakeholders understand the relevant parts of the model completely? Could the stakeholders understand the relevant parts of the model correctly? Could the stakeholders understand the relevant parts of the model easily? How often did the model get interpreted to say one thing later to find out that the model was actually saying something else? Did people disagree about the model?19 Was the level of abstraction correct? Was there any filtering (hiding of information) available? Was the model useful20? Pragmatic Support 21 Did the model include any supplementary material (e.g. implementation guides, procedural models) How did you ensure the model was laid out correctly (tool checklist guidelines? Were the models tailored to suit individual/groups users22? Does the tool/model support automatic tailoring of the models to suit audience23? Does the tool support simulation24? Were there any group discussions about the meaning of the model?25 Did the model include any supplementary material (e.g. extended explanations)? Did you do any training in the content as related to the model? Was the scope of the model clearly defined26? Comparability, inter model consistency of application of other guidelines. Was there a formal way of the breaking up/linking the models (hierarchy or division)27?

19 This could be a social aspect

20 More of a social perspective, but supported as pragmatic by shanks (print out) and FRISCO p145

21 things that don’t fall under the specific language, it is there to support the understanding and use

22 (Gulla and Brasethvik 2000) Pragmatic variation paradox: prag. Var. increases user comprehension, but complicates the formation of a common understanding of the domain.

23 (Gulla and Brasethvik 2000) [they said that despite tailoring the interpretations were consistent]

24 (Gulla and Brasethvik 2000) p

25 social level interaction

26 Based on FRISCO definition of pragmatics as “usefulness”


QUT Page 230

Could you contact the developers of the model for clarification? How well did the area of the model overlap with your area? How easy was it to modify the reference models to suit the situation (e.g. update, configure, customize, modify)?28 How easily were the models displayed and distributed?29 Part of Pragmatic support is increasing the Audience-Language fit30: How well did the stakeholders understand the language used? How intuitive was the language to the audience? How easily could the language be used? A-L Support What training did the stakeholders have with the language used by the reference model? What experience did the stakeholders have with the language used by the reference model? Was there any explanatory material on the language used? Did you create any? Were there any changes to the language made to fit the audience? Part of Pragmatic Support is Audience-Domain fit: How familiar were the stakeholders with the area of the reference model in a general / (organizational) project specific sense? A-D Support What training did the stakeholders have with the area of the reference model? Based on this notion, do you think that the <name of ref model> was useful/ successful in this context?> (If yes, explain how?…if not, why not?) (Gulla and Brasethvik 2000)

27 Krogstie 95 some of the means to achieve pragmatic quality is structuredness, aesthetics

for diagram layout

28 the format in which the reference model comes will affect its easy of modification

29 associated with physical, from Gulla (Gulla and Brasethvik 2000) but This is really more of a physical level

30 Krogstie 1995 p225, actors familiarity with languages will effect their comprehension of a model in a specific langauge


QUT Page 231

Appendix B Examples of classifications of Levels of

Reuse

The two models below were classified as having a high degree of reuse.

Figure 77: Example of High Level of Re-Use Classification (Incident Management)

The two model extracts below were classified as having a medium degree of

reuse.

Figure 78: Enterprise model example for medium re-use (Detect Incident)

incident detectedby client

incident detectedby support centre

staff

choosenotification method

phone methodchosen

email methodchosen

in person methodchosen

fax methodchosen

mail methodchosen

third party

client

phoneservice desk

sendan email

faxa letter

visithead office

sendmail

citecstaff

DetectIncident

RecordIncident

AssessIncident

ResolveIncident

CloseIncident

IncidentManagement

Enterprise model

1.1 DetectIncident

1.2 RecordIncident

1.3 AssessIncident

1.4 ResolveIncident

1.5 CloseIncident

1. IncidentManagement

Reference model


QUT Page 232

Figure 79: Reference model example for medium re-use (Detect Incident)

The two model extracts below were classified as having a low degree of

reuse. Both were taken from the start of the Record Incident process.

Figure 80: Enterprise model example for low re-use (Record Incident)

Techniciandetects incident

Choose NotificationMethod

Phone methodchosenEmail method Chosen

Phone Help Desk

User detectsincident notin support

enabled application

RecordSymptoms

Webreportingchosen

RecordSymptoms

Service Staff

User User

User

User

Commentsentered

AssignClassification

DetermineResolution

ShiftOperator

IncidentKnowledge

ShiftOperator

IncidentKnowledge

IncidentResolutionnot known

Incident mustbe resolvedat Level 2

IncidentResolution

known

Incident isa ServiceRequest

SLA


QUT Page 233

Figure 81: Reference model example of Low Level of Re-Use (Record Incident)

1.2.1 Create IncidentRecord

Incident RecordCreated from user

phone call

Incident RecordCreated from user

electronic correspondance

Incident RecordCreated from

Application report

Service Desk notified


QUT Page 234

Appendix C Survey Forms Reference model use and impressions

Explanation: The “models” refers to the ARIS models (eEPC and Value Chain). The “books” refers to the textual descriptions [including the models included within the text]. Please put a N/A to questions that are not appropriate or that you cannot answer. Please try to answer all the questions. In the comparison fields please mark the box that indicates your choice. e.g. the following would indicate that your preference is blue, but it is not a strong favourite. Which is your favourite colour? Blue X Red PART 1: Demographics of Respondent How much modelling experience or training did you have before the project? (e.g. ITN252) Did you have any training or experience in IT services or Incident Management / Help Desk? How did you used the reference material (please tick any box/es as appropriate)?

Books Models Process Identification 3 4 AS-IS Modelling Guidance (template) 1 4 AS-IS Model analysis 3 3 TO-BE Modelling Guidance (template) 0 5 Performance metrics identification 1 3

Other: _____________________________

PART 2: Reference assessment The Books Was the use of the ITIL books helpful for the project? If yes, in what ways? Can you quantify the benefit in terms of time? What did you gain from the use of ITIL books? Which book(s) / chapter(s) did you use? What could be improved in the books? The Models Was the use of the process models helpful for the project? If yes, in what ways? Can you quantify the benefit in terms of time? What did you gain from the use of models? Which models did you use? What could be improved in the models? Direct Comparison Which contained more ambiguities? Books Models Which was quicker to understand? Books Models Which contained the most details? Books Models Which gave the best overview? Books Models Which one was easier to understand? Books Models

Which was more precise? Books Models Please select whether the books or the models are more likely to increase the following risks:


QUT Page 235

Please rate which source was more helpful under the following criteria: Provides a basic solution, reducing the need for development from scratch.

Books Models

The best practice knowledge was accepted by the user/customer, efforts of convincing them was reduced

Books Models

The material allowed semantic errors to be detected in the AS-IS models. Books Models

The material allowed syntactic errors to be detected in the AS-IS models. Books Models

Ideas from the material can be easily incorporated into the TO-BE Books Models

The material was easy to discuss to reach an agreement on meaning Books Models

The relevance of the material could be easily determined. Books Models

The material helped to understand and use the modelling language Books Models

The material made it easy to understand the domain Books Models

Comparison of Use Which did you use most? Books Models Are the models are a good enhancement of the books content? y/n Future Use If I have to decide about either using the books or the models I would use the

• Books • Models

Why? Optimum benefit for similar projects in the future would be achieved through using

• nothing • the books only • the models only • the books and the models.

Other comments?

The developed TO-BE model is not the best for the specific situation Books Models

The time spent understanding the reference model was not worth the benefits gained

Books Models

Reliance on the reference model limited creativity and innovation Books Models


QUT Page 236

Appendix D Detailed Survey Results How did you use the reference material Books Models

Process Identification 3 4 AS-IS Modelling Guidance (template) 1 4

AS-IS Model analysis 3 3 TO-BE Modelling Guidance (template) 0 5

Performance metrics identification 1 3

Other: _____________________________ 0 0

Did the models or the books: Average St Dev

contain more ambiguities? 3 1.4

quickest to understand? 3.4 1.5

contain the most details? 2.8 0.8

give the best overview? 4 0.7

make understanding easier? 4.2 0.8

provide more accuracy? 2.6 1.3

Which was more likely to increase the risk that:

The developed TO-BE model is not the best for the specific situation 3 1.5

The time spent understanding the material was not worth the benefits gained 2.2 1.0

Reliance on the reference model limited creativity and innovation 2.6 1.1

Where the models or the books more helpful in:

providing a basic solution, reducing the need for development from scratch. 2.8 1.6

allowing semantic errors to be detected in the AS-IS models. 4 1.2

allowing syntactic errors to be detected in the AS-IS models. 4 1.2

making it easy to incorporated ideas into the TO-BE 4.2 0.8

reaching an agreement on meaning 2.6 0.8

determining the relevance of the material 3.2 0.8

understanding and using the modelling language 3 1.5

making it easy to understand the domain 2.4 0.8

Which did you use most? 2.4 1.1 Table 33: Results of the Likert questions comparing the books and models

NOTE: 1 is the books while 5 is the models


QUT Page 237

Appendix E Company Profiles31

Citec The fourth of the top ten IS outsourcing participants is Citec (#9) who

provided four participants at different times during the focus group sessions.

Citec is a government owned commercialised company stated in 1964 and

commercialised in 1992. Citec participants were managers with

responsibilities which ranged across the strategic management areas. They

brought a unique and valuable knowledge and experience taken from a

customer base of 57% government and 43% public clients. Citec have offices

in 5 Australian states and a 2001 revenue of AUD120 million and total staff of

700 plus people. Citec do not offer full service outsourcing, and focus on

integrated infrastructure management, e-Business solutions and application

outsourcing (Benson 2002).

Computer Science Corporation The participants CSC manage the IS needs for the worlds largest mining

company and have access to the collective knowledge of a multinational

organisation which has operated since 1959 in the United States and since

1970 in Australia. Knowledge management is a formalised process within

CSC and the participants were able to utilise this network of people and

databases in support of the research project. CSC has more than 4500

employees in Australia almost all of which work in the services market. IDC

report that CSC operates across the banking and financial services,

government and manufacturing industries (Benson 2002).

Corporate Service Agency Corporate Services Agency (CSA) was the only other government participant

in the research project. CSA was able to add to the input of Citec from the

view of a pure ASP with no hosting of applications. CSA was established in

July 1996 as a shared service provider of finance, human resource and

administrative services. The organisation is jointly owned by the Department

31 Many of these profiles are copied from Huxley’s masters thesis (Huxley 2003) with permission.


QUT Page 238

of Natural Resources and Mines (NR&M) and the Department of Primary

Industries (DPI). The participant’s knowledge and experience stem from their

roles as managers of the SAP R/3 system delivered to NR&M and DPI along

with a number of legacy systems. CSA provides a full range of services to

support these systems and effectively operates as an Applications Service

Provider (ASP) to its clients. The agency’s revenue base is around $22M per

annum and there are approximately 260 full time equivalent staff (Corporate

Services Agency 2002).

Deloitte Touche Tohmatsu The two participants from Deloitte Touche Tohmatsu (DTT) were senior

managers within the Management Solutions group. They brought a wealth of

knowledge and experience to the research by providing insights gained from

their own experience but also that of the 259 Australian partners and 2554

professional staff. Like many of the large consulting firms DTT operates a

knowledge database on a global scale. The participants were thus able to

provide a global view of the industry. For the financial year ending June 2002

there was a Net Revenue of AUD573 Million.

The Management Solutions groups Deloitte also provides consulting

services, specialising in Business and Technology Strategy, Collaborative

Supply Chain Management, Strategic Sourcing and Procurement,

eMarketplaces, Systems Implementation, Process Transformation, Finance

Transformation, Human Resources and Change Management, CRM, and

Applications Integration (Deloitte Touche Tohmatsu 2002) .

EDS Consulting The participant from EDS operates at the operations end of the business

managing the takeover and set-up of new clients. This participant brings a

wealth of experience and knowledge to the construction of the physical and

informational infrastructure of complex outsourcing contracts. EDS is the

second largest IS outsourcing company in Australia with 26% of the IS

outsourcing market in revenue terms. In Australia the 2001 revenue reached

AUD 1.45 billion. Operations in Australia were established in 1986 and it has

some 7000 employees with operations in Banking and Finance Services,


QUT Page 239

Communications, Government, the Manufacturing industry and

Transportation sectors (Benson 2002).

Hitachi Data Systems Hitachi Data Services (HDS) is a private wholly owned subsidiary of Hitachi

Ltd founded in 1989 (Japans largest electronics company). The participant

from HDS comes from a true niche player within the IS outsourcing industry.

This company specialises in providing remote data base services for all types

of applications (not just ES systems). This participant was able to provide

insights to the research gained from being a highly focussed specialist. As a

private company HDS do not publish revenue or employee figures, all

information about the company is consolidated in the group reports of the

Hitachi Corporation, Japan (Connected Corporation 2001).

IBM Global Services Australia The participant from IBM Global Services Australia (GSA) is a member of the

Global and Asia Pacific focus groups able to provide a global perspective as

well as understanding the uniqueness of the Asia Pacific and Australian

markets. IBM GSA has 10,500 employees in Australia with revenue of AUD

3.3 billion in 2001 of which AUD 1.725 billion was for Services. The company

operates mostly in the IS outsourcing and network infrastructure

management service fields competing in the Banking and Finance Services

sectors, Communications, Government, Manufacturing and Transportation

sectors. IBM Global Services support users in Australia, Singapore,

Malaysia, Thailand, Philippines, Indonesia, Hong Kong, Taiwan and Korea

from data centres in Sydney, Melbourne and Ballarat (Benson 2002; IBM

Global Services Australia 2002).

Mincom Mincom was founded in 1979 and is still majority owned by current and

former employees of Mincom (75.80%). The participant from Mincom brings

a specialised knowledge and experience in managing an outsourcing

business with enterprise system products produced by Mincom itself. This

was a unique perspective in the research project with no other participant

having such close and easy access to this type of knowledge. Mincom has


QUT Page 240

over 1100 employees in 18 offices and operates in 40 countries. Revenue for

the 2001/2002 financial year was AUD 207.8 million. The company develops

and sells enterprise system software and provides IS outsourcing services for

its range of enterprise systems. It has a reputation for producing the world’s

best enterprise asset management systems for asset intensive industries

(such as utilities, mining and transport). (Hoover's Online 2002; IBIS World

2002; Paul Budde Communication 2002) (Mincom 2002).

Parmalat Pty Ltd The ninth participant and the only in-house organisation was Parmalat with

its head office in Milan Italy. The participant from their Brisbane headquarters

was able to provide the in-house view of enterprise system service provision.

Parmalat operate one of the latest versions of SAP R/3 in Australia with the

full suite of e-Business modules. They have a progressive and innovative IT

culture operating within the dairy industry which is a 24hours, 7 days a week

business. This drives the need for an IT service which is critical to product

management and thus a participant with a proven skills and knowledge in

developing effective and highly efficient processes within enterprise systems.

In 2001, Parmalat operated in 30 countries, with 146 plants employing

approximately 36, 000 employees and consolidated (group wide) sales of

AUD 13.5 billion (Parmalat 2001).

Queensland Rail Queensland Rail (QR) is a Queensland state Government owned corporation

that provides transport and logistics business solutions to a diverse range of

customers throughout the State, Australia and overseas. With annual

operating revenue of over $2 billion, 9500km of narrow gauge track, and

around 14,000 staff, QR is one of Australia’s largest and most modern rail

networks.

REALTECH AG The tenth company was the industry partner REALTECH and two members

of this company participated in the research. These participants were able to

provide valuable input from both the perspective of an outsourcing company

specialising in remote hardware and operating system maintenance and as a


QUT Page 241

service provider to outsourcing companies as well. This enables the

participants to have a wide experience with the processes of many Australian

and international companies. The company itself is described earlier in the

chapter.

Telstra Telstra is majority owed by the Commonwealth Government of Australia after

going through partial privatisation in 1997, and provides information and

telecommunications services, throughout Australia and the Asia-Pacific.

Telstra’s revenue in 2002 was over $10 billion with over 17 million voice and

data services in operation employing over 40,000 staff.

Documents

Reference Models for IT Service Provision - QUT ePrintseprints.qut.edu.au/16047/1/Chris_Taylor_Thesis.pdf · 2.3.5 Example of Reference Model Classifications ... eTOM Business Process