1

A SIMULATION CONCEPTUAL MODELLING METHODOLOGY FOR SUPPLY CHAIN

MANAGEMENT APPLICATIONS

MILES WEAVER

DOCTOR OF PHILOSOPHY

ASTON UNIVERSITY

OCTOBER 2010

This copy of the thesis has been supplied on condition that anyone who consults it is understood to recognise that its copyright rests with the author and that no quotation from this thesis and no information derived from it may be published without proper acknowledgement.

2

Aston University

A Simulation Conceptual Modelling Methodology for Supply Chain Management Applications

Miles Weaver

Doctor of Philosophy

2010

Thesis summary The research focuses upon the development of a simulation conceptual modelling methodology for SCM applications (termed the ‘SCM2’). The originality of the SCM2 is that it combines a prescribed procedure for simulation conceptual modelling with supply chain domain-specific knowledge. This procedure is used to guide participants to create a non-software specific description of the simulation model to be developed, in the context of SCM applications. The SCM2 is presented as a series of seven phases, associated steps, who participates in each step, information needs and points of entry between steps. The SCM2 is entered when a client has a supply problem to be evaluated using a simulation approach. The supply problem is described in terms of the improvement(s) to be evaluated, for a given objective(s) within its supply setting. From this description, how each objective is to be measured and how each improvement is to be represented is determined. The interconnections between model components and the immediate supply setting are discriminated, model boundary formulated and level of detail designed. The output from the SCM2 is a documented and validated conceptual model. The need for a greater understanding of how to perform the conceptual modelling stage, as part of a simulation project, is shown to be of great significance and relevance. In particular the thesis argues that no methodologies exist that can guide participants in a simulation project through the process of creating a simulation conceptual model. A research methodological programme is designed to review existing modelling practice, form a specification for the methodology, develop an outline for the SCM2, detail the outline through refinement and application and a preliminary validation of the SCM2. The specification is formed to identify a set of requirements that the methodology should address. The methodology is developed to meet the specification by refining the outline design using two developmental cases of typical and complex supply chain problems. The outline design is founded on existing practice for conceptual modelling and identifies ten key concepts that have been synthesised by considering the design issues for each requirement identified in the specification. A major advance made by this thesis is a suggestion that the process of conceptual modelling could benefit from utilising domain knowledge provided by the Supply Chain Council SCOR model. It is demonstrated that using SCOR is a powerful way to enable a more focused and efficient procedure for conceptual modelling. The methodology incorporates the key concepts and aligns these with a general process for conceptual modelling. A preliminary validation with a different supply chain illustration demonstrates that the methodology is initially ‘feasible’ and has ‘utility’. Future testing is required in different industrial contexts with actual participants and an opportunity exists to extend the methodology into a web-based application tool.

Keywords Supply chain management, conceptual modelling, simulation, performance evaluation

3

To my late grandfather for whom I hold great respect and pride

Hon. Alderman Albert [Tom] Matthews MBE

'Forever my inspiration'

Orchards gay with blossom, Beauty, there to see,

Hollows where breeze is tender, Moorlands where wind breaks free;

Sowing, Lambing, and Harvest, Overlooked by Giant Clee,

Hop Kilns, Farmsteads, and TENBURY, This is happiness is for me.

Source: Anon

4

Acknowledgements

Firstly, I would like to sincerely thank Dr. Doug Love and Dr. Pavel Albores for supervising this PhD

thesis and investing their time in mentoring my early research career. Their energy, drive and

support has inspired, empowered and enabled me for which I am entirely grateful.

I would like to warmly acknowledge my family and friends for their continued support,

encouragement and understanding throughout my doctoral studies. My parents, David and Pat

Weaver, have been a source of determination throughout my life providing the bite to seek

fulfilling goals, taking me to new horizons. My sister, Elaine Dolby and my brother, Nigel Weaver,

have been there for me during the highs as well as the lows. Sarah Greenhouse provided me with

strength when times got challenging; I am entirely grateful for her support, detailed discussions

and time invested in me during the writing up of my thesis. Similarly, Sarah’s mother Josie kept

smiling and offering her time by proof-reading the final drafts – I shall never forget the support

and encouragement from ‘Team Greenhouse’. My two best friends, Paul and Neil, for helping me

to switch off from time to time. I would also like to thank certain colleagues and friends in

particular: Alfred, Anita, Breno, Deycy, Emma, Eleanor, Helen, James, Joanna, Naomi, Natalia, Nick

T, T.T., Tony and Wenshin, who I have had the pleasure to work with or interact with during such

stimulating times.

I would also like to thank researchers who have supported and shaped my doctoral work. In

particular: Prof. Don Taylor (Virgina Tech), Prof. Rafaela Alfalla-Luque and Dr. Carmen Medina-

Lopez (both from Seville University). The data for the industrial development case was gathered

by the FUSION research group (collaboration between Aston, Liverpool and Strathclyde). I am

grateful for all the support and fun times while conducting this research, and look forward to

future collaborations and projects.

5

Notations used in thesis

BeerCo Beer company supply chain case

CarCo Car company supply chain case

CHR Central headrests manufacturer

CM Conceptual Modelling

CoffeePotCo Coffee pot supply chain case

DES Discrete Event Simulation

GSFC Global Supply Chain Forum

LA Luxury Automotive Manufacturer

MABM Multi-Agent Based Modelling

SCM Supply Chain Management

SCM2 Simulation conceptual modelling methodology for supply chain management

applications

SCOR Supply-Chain Operations Reference-model

SD Systems Dynamics

SME Subject Matter Expert

SS Seat set manufacturer

SSM Soft Systems Methodology

T Tracks manufacturer

6

Publications

During the period of conducting this research the following publications have been contributed to: Albores, P., Love, D., Weaver, M., Stone, J. & Benton, H. (2006) An evaluation of SCOR modelling tools and techniques. Technology and Global Integration. IN: Proceedings of the Second European Conference on the Management of Technology. Aston Business School, Birmingham, UK. Taylor, G. D., Love, D. M., Weaver, M. W. & Stone, J. (2008) Determining inventory service support levels in multi-national companies, International Journal of Production Economics, 116(1), 1-11. Niranjan, T., Weaver, M., (2010) A unifying view of goods and services supply chain management, The Service Industries Journal, iFirst Article, 1–20. Niranjan, T., Weaver, M., Pillai, S., (2009) Bridging between goods and services SCM: Some fresh perspectives. Green Management Matters. IN: Proceedings of the Academy of Management Annual Meeting. Chicago, Illinois, USA Weaver, M., Love, D. & Albores, P. (2008) Supply chain improvement options and their decision variables. Tradition and Innovation in Operations Management. IN: 15th Annual EurOMA Conference of the European Association of Operations Management. University of Gronigen, Netherlands. Weaver, M., Love, D. & Albores, P. (2007a) A decision aid to select techniques to evaluate supply chain improvement options. Managing Operations in an Expanding Europe. IN: 14th Annual Conference of the European Association of Operations Management. Bilkent University, Ankara, Turkey. Weaver, M., Love, D. & Albores, P. (2006) Towards the development of a supply strategy evaluation methodology. Moving Up the Value Chain. IN: Conference of the European Association of Operations Management. Strathclyde University, Scotland, UK.

7

Table of Contents Thesis summary ................................................................................................................................. 2

Keywords ......................................................................................................................................... 2 Acknowledgements ......................................................................................................................... 4 Notations used in thesis .................................................................................................................. 5 Publications ..................................................................................................................................... 6 List of figures in thesis ................................................................................................................... 11 List of tables in thesis .................................................................................................................... 12

Chapter 1 Introduction ................................................................................................................. 14 1.1 Research background ........................................................................................................ 14 1.2 Research aims, objectives and programme ...................................................................... 16 1.3 Justification for the research focus ................................................................................... 18 1.4 Outline of the thesis .......................................................................................................... 19 1.5 Delimitation of scope and definitions ............................................................................... 22 1.6 Chapter summary .............................................................................................................. 24

Chapter 2 Research issues in conceptual modelling for SCM applications .................................. 26 2.1 Scope and selection of contributions in literature review ................................................ 27 2.2 Importance of evaluating supply chain problems ............................................................. 29 2.3 Complexity of evaluating supply chain problems ............................................................. 31 2.4 Role of simulation to evaluate supply chain problems ..................................................... 32

2.4.1 Range of approaches used in simulation ................................................................. 33 2.4.2 Extent and usage of simulation for research ........................................................... 34

2.5 Role of conceptual modelling in simulation projects ........................................................ 37 2.5.1 Importance of conceptual modelling in a simulation project .................................. 38 2.5.2 Key debates around the nature of conceptual modelling ....................................... 38 2.5.3 Defining conceptual modelling for supply chain problems ..................................... 40

2.6 Understanding of CM for SCM simulation applications .................................................... 43 2.6.1 General issues in understanding of conceptual modelling ...................................... 43 2.6.2 Application of the process of conceptual modelling for SCM problems ................. 45

2.7 Usefulness of a CM methodology for SCM applications ................................................... 46 2.8 Benefits of developing a conceptual modelling methodology for SCM applications ....... 48 2.9 Chapter summary .............................................................................................................. 49

Chapter 3 Research programme for the development and preliminary validation of the SCM2 . 50 3.1 Justification of methodological approach ......................................................................... 50

3.1.1 Methodological approaches for the development of methodologies ..................... 51 3.1.2 Key methodological issues in the area of developing a methodology..................... 52 3.1.3 General methodological issues for developing the SCM2 ........................................ 53 3.1.4 Justification of five stage approach .......................................................................... 61

3.2 Research programme and methods .................................................................................. 64 3.2.1 Overview of research programme and methods ..................................................... 64 3.2.2 Stage I: Review of existing conceptual modelling practice ...................................... 65 3.2.3 Stage II: Forming the specification for SCM2 ............................................................ 67 3.2.4 Stage III: Discussion of the outline design for the SCM2 .......................................... 68 3.2.5 Stage IV: Discussion of the detailed and refined design of the SCM2 ...................... 70 3.2.6 Stage V: Preliminary validation of the SCM2 ............................................................ 71

3.3 Theory building through existing case study applications ................................................ 73 3.3.1 Involvement and reflexivity of the researcher ......................................................... 74 3.3.2 Consistency of the process ....................................................................................... 74 3.3.3 Choice of supply chain application cases ................................................................. 75 3.3.4 Data collection methods .......................................................................................... 76

3.4 Limitations of research approach ..................................................................................... 77 3.5 Validity and reliability of the research .............................................................................. 78

8

3.6 Ethical considerations and issues ...................................................................................... 78 3.7 Chapter summary .............................................................................................................. 79

Chapter 4 Review of existing CM (Stage I) .................................................................................... 80 4.1 Approaches to conceptual modelling in practice ............................................................. 80

4.1.1 Principles in conceptual modelling .......................................................................... 81 4.1.2 Methods of simplification ........................................................................................ 82 4.1.3 Modelling frameworks ............................................................................................. 85

4.2 Problems encountered in simulation modelling ............................................................... 86 4.3 Communicating and representing the conceptual model ................................................ 87

4.3.1 Simulation project specification ............................................................................... 88 4.3.2 Representing the conceptual model ........................................................................ 89

4.4 Validation of conceptual models ...................................................................................... 91 4.5 Chapter summary .............................................................................................................. 94

Chapter 5 Forming the specification for the SCM2 (Stage II) ........................................................ 95 5.1 Requirements for an ‘effective’ conceptual model .......................................................... 95

5.1.1 Four requirements of a conceptual model .............................................................. 96 5.1.2 Building ‘valid’ and ‘credible’ models ...................................................................... 97 5.1.3 Fundamental need to keep the model ‘simple’ ....................................................... 98

5.2 Requirements for ‘good’ methodologies .......................................................................... 98 5.3 Requirements for conceptual modelling of supply chain problems ............................... 100

5.3.1 Handle the complexity and detail of supply chain improvements ........................ 101 5.3.2 Address a range of supply chain objectives ........................................................... 105 5.3.3 Identify interconnections with the supply setting ................................................. 106

5.4 Chapter summary ............................................................................................................ 106 Chapter 6 Outline design for the SCM2 (Stage III) ....................................................................... 108

6.1 Design issues for developing a ‘good’ methodology ...................................................... 109 6.1.1 General guide for conceptual modelling ................................................................ 109 6.1.2 Role of participants in the process of conceptual modelling ................................. 111 6.1.3 Points of entry in the methodology ....................................................................... 112

6.2 Design issues for creating an ‘effective’ conceptual model ............................................ 113 6.2.1 Keep the model as ‘simple’ as possible .................................................................. 113 6.2.2 Creating a ‘valid’ and ‘credible’ conceptual model ................................................ 115

6.3 Design issues for the domain specific needs for creating a CM...................................... 117 6.3.1 Opportunities to use a process reference model for creating a CM ..................... 117 6.3.2 Identification of a suitable process reference model for creating a CM ............... 118

6.4 Using SCOR for conceptual modelling ............................................................................. 121 6.4.1 Using SCOR to describe supply chain improvements ............................................ 122 6.4.2 Using SCOR to describe supply chain objectives .................................................... 122 6.4.3 Using SCOR to determine the interconnections with the supply setting .............. 124

6.5 Presentation of outline design ........................................................................................ 125 6.5.1 Key concepts to be incorporated into the methodology ....................................... 125 6.5.2 Linking key concepts to phases in the SCM2 .......................................................... 128

6.6 Chapter summary ............................................................................................................ 130 Chapter 7 Detailed design for SCM2 (Stage IV) ........................................................................... 132

7.1 Overview of the SCM2 ..................................................................................................... 132 7.2 Presentation of the development cases ......................................................................... 136

7.2.1 Development case 1: BeerCo ................................................................................. 136 7.2.2 Development case 2: CarCo ................................................................................... 137

7.3 Application of the development cases to refine and detail the SCM2 ............................ 138 7.3.1 Phase 1: Describe the supply problem from the client’s perspective ................... 139 7.3.2 Phase 2: Determine how each objective is to be measured .................................. 144 7.3.3 Phase 3: Determine how each improvement is to be represented ....................... 150

9

7.3.4 Phase 4: Determine how the inputs and their sources interconnect .................... 153 7.3.5 Phase 5: Formulation of the model boundary ....................................................... 157 7.3.6 Phase 6: Design of the detail of the model ............................................................ 166 7.3.7 Phase 7: Validate and document the conceptual model ....................................... 172

7.4 Implementing the SCM2 using a spreadsheet application ............................................. 177 7.5 Alignment of detailed design of the SCM2 against specification ..................................... 177

7.5.1 Meet the requirements for an ‘effective’ conceptual model ................................ 178 7.5.2 Meet the requirements of ‘good’ methodologies ................................................. 179 7.5.3 Meet the requirements for conceptual modelling of supply chain problems ....... 181

7.6 Chapter summary ............................................................................................................ 182 Chapter 8 Preliminary validation of the SCM2 (Stage V) ............................................................. 184

8.1 Presentation of validation case: CoffeePotCO ................................................................ 184 8.2 Application of SCM2 to preliminary validation case ........................................................ 185

8.2.1 Phase one: Describe the supply problem............................................................... 186 8.2.2 Phase two: Determine how each objective is to be measured ............................. 187 8.2.3 Phase three: Determine how each improvement is to be represented ................ 189 8.2.4 Phase four: Determine the model inputs and source process elements ............... 190 8.2.5 Phase five: Formulate the model boundary .......................................................... 191 8.2.6 Phase six: Designing the model detail .................................................................... 194

8.3 Purpose of the evaluation of the methodology .............................................................. 195 8.3.1 Criteria for evaluating the feasibility of the SCM2 ................................................. 195 8.3.2 Criteria for evaluating the utility of the SCM2 ........................................................ 196

8.4 Evaluation of the initial feasibility of the SCM2 ............................................................... 196 8.4.1 Evaluation of the availability of information required by the SCM2 ...................... 197 8.4.2 Evaluation of the availability of information provided by the SCM2 ..................... 198

8.5 Evaluation of the initial utility of the SCM2 ..................................................................... 199 8.5.1 Relevance of output derived from the SCM2 ......................................................... 200 8.5.2 Usefulness of the output derived from the SCM2 .................................................. 200 8.5.3 How the methodology could be facilitated............................................................ 202

8.6 Identification of issues for testing ................................................................................... 204 8.6.1 Feasibility ............................................................................................................... 204 8.6.2 Utility ...................................................................................................................... 204 8.6.3 Usability .................................................................................................................. 205

8.7 Opportunities to improve the SCM2................................................................................ 206 8.7.1 Role and impact of automating the methodology ................................................. 206 8.7.2 Strengthening the utilisation of domain knowledge ............................................. 207 8.7.3 Development of a web based tool ......................................................................... 208

8.8 Chapter summary ............................................................................................................ 208 Chapter 9 Conclusion and future work ....................................................................................... 210

9.1 Original contribution made by the thesis ....................................................................... 210 9.1.1 Primary research contribution ............................................................................... 211 9.1.2 Secondary research contributions ......................................................................... 217

9.2 Conclusions from the research objectives and questions .............................................. 219 9.2.1 Objective one: Documentation of required specification ...................................... 219 9.2.2 Objective two: Development of SCM2 addressing the specification ..................... 220 9.2.3 Objective three: Preliminary validation of the SCM2 ............................................. 221

9.3 Limitations of study ........................................................................................................ 222 9.3.1 Application in different industrial contexts with primary data .............................. 224 9.3.2 Use of different facilitators (potential users) to follow the SCM2 ......................... 224 9.3.3 Validation of the usability of the SCM2 .................................................................. 225

9.4 Implication for further research and practice ................................................................ 225 9.5 Chapter summary ............................................................................................................ 227

10

References................................................................................................................................... 229 Appendix A Principles/observations made in the design of the SCM2 ...................................... 251 Appendix B Actual practice to be modelled (BeerCO development case) ................................ 260 Appendix C Actual practice to be modelled (CarCO development case) .................................. 263 Appendix D Illustrations of model components to be developed into a computer model ....... 266 Appendix E Example process flow diagrams for the BeerCo development case ...................... 268 Appendix F Flowchart of the CoffeePotCo computer simulation model .................................. 270 Appendix G Comparison of practice to be modelled and CoffeePotCo computer model ........ 271 Appendix H Evaluation of how information is used and provided in the preliminary validation case ................................................................................................................................ 275 Appendix I Issues for testing the ‘usability’ of the SCM2 ......................................................... 277

11

List of figures in thesis Figure 1.1 Overview of the thesis structure and research programme .................................... 20 Figure 2.1 Classification of supply chain simulation approaches .............................................. 34 Figure 3.1 Overview of research programme ........................................................................... 64 Figure 6.1 Example of SCOR inputs and outputs to a decomposed business process ............ 124 Figure 7.1 Overview of the SCM2 ............................................................................................ 133 Figure 7.2 Structure and flows in the BeerCo development case ........................................... 137 Figure 7.3 A simplified diagram of CarCo’s supply chain ........................................................ 138 Figure 7.4 ‘Reliability’ metric structure with an example of a level 3 metric ......................... 147 Figure 7.5 Calculation and data collection needs for RL.2.1 % of orders delivered in full ..... 148 Figure 7.6 Extract of the SCOR descriptions of best practices ................................................ 151 Figure 7.7 Example of the inputs of a source process element described in SCOR ................ 154 Figure 7.8 Process elements, inputs, source process element and suggested source actor .. 155 Figure 7.9 Extract of the list of inputs considered for S1.1 in the CarCo development case . 156 Figure 7.10 Extract of how phase four was completed for the CarCo development case ....... 157 Figure 7.11 Extract of the output from phase four that is transferred (in step 5.1) ................ 160 Figure 7.12 Extract of phase five from the BeerCo development case for the Wholesaler ..... 163 Figure 7.13 Template used to check the linkages between processes in the CarCo development

case......................................................................................................................... 165 Figure 7.14 Tracing back the inputs of included processes from a data source ....................... 166 Figure 7.15 ‘Phantoms’ in the CarCo development case (inputs shown for D1.10 SS) ............ 168 Figure 7.16 Extract of actual practice descriptions in the BeerCo development case ............. 169 Figure 7.17 Extract of how actual practices can be ‘consolidated’ for the CarCo development

case......................................................................................................................... 170 Figure 8.1 Graphical illustration of CoffeePotCo supply problem .......................................... 185 Figure 8.2 Interconnection identified for each process element in the model ...................... 190 Figure 8.3 Formulation of the model boundary (CoffeePotCo) .............................................. 191 Figure 8.4 Promoted, core and simplified process elements for the CoffeePotCo validation

case......................................................................................................................... 194 Figure E.1 Retailer plan and place order in BeerCo development case .................................. 268 Figure E.2 Fulfil order in BeerCo development case ............................................................... 269 Figure F.1 Flowchart of computer simulation program for CoffeePotCo ............................... 270

12

List of tables in thesis Table 2.1 Selection of contributions that meet search terms in each academic database ......... 29 Table 2.2 Classification of simulation approaches ....................................................................... 35 Table 3.13 Similarities between an iterative triangulation and grounded theory method .......... 61 Table 3.24 Design questions and issues to address the requirements ......................................... 71 Table 3.3 5 Criteria for assessing a process framework or methodology ...................................... 73 Table 3.4 6 Summary of cases used to develop and validate the methodology............................ 76 Table 4.17 Approaches to conceptual modelling .......................................................................... 81 Table 4.28 Research contributions on simulation model simplification (advice and methods) ... 84 Table 4.39 Potential pitfalls in simulation related to conceptual modelling ................................ 86 Table 4.410 Reasons for increasing complexity (some consideration in the SCM domain) ............ 87 Table 4.511 Methods used to document CM with examples in the SCM literature ....................... 90 Table 5.1 Four requirements for a conceptual model ................................................................. 96 Table 5.2 Platts (1994) characteristics of successful strategy formulation methodologies ...... 100 Table 5.3 Identification of the complexity of a supply problem ................................................ 103 Table 5.4 Identification of the detail of supply chain improvements ........................................ 104 Table 5.5 Aims and requirements for the SCM2 ........................................................................ 106 Table 6.1 Proposed stages for conceptual modelling in general suggested in the literature ... 110 Table 6.2 Incorporating model simplification advice and methods into a methodology .......... 114 Table 6.3 Documentation and validation requirements for the SCM2 ...................................... 116 Table 6.4 Role of domain knowledge in conceptual modelling ................................................. 117 Table 6.5 Comparison of supply chain process reference models ............................................ 120 Table 6.6 Domain knowledge offered by SCC SCOR model ....................................................... 121 Table 6.7 Examples of two typical supply chain problems ........................................................ 122 Table 6.8 Example of SCOR detail extracted for improvements ............................................... 122 Table 6.9 Example of extracting SCOR performance measures ................................................ 123 Table 6.10 Key concepts to be included in the design of the SCM2 ............................................ 126 Table 6.11 Linking key concepts, conceptual modelling process with phases in the SCM2 ........ 128 Table 6.12 Outline of the methodology: Phases, inputs and outputs......................................... 130 Table 7.1 Detailed steps for phase one of the SCM2 ................................................................. 140 Table 7.2 Description of the objective(s) of study ..................................................................... 141 Table 7.3 Illustration of the description of the improvements selected ................................... 142 Table 7.4 Illustration of the description of the supply problem setting .................................... 143 Table 7.5 Illustration of how each improvement could achieve each objective ....................... 143 Table 7.6 Detailed steps for phase two of the SCM2 ................................................................. 146 Table 7.7 Description of the supply chain metrics ..................................................................... 147 Table 7.8 Description of calculation and data source requirements for each metric ............... 149 Table 7.9 Description of the nature of measurement for each metric in both development cases .................................................................................................................................... 149 Table 7.10 Detailed steps for phase three of business methodology ......................................... 150 Table 7.11 List of processes at three levels of process detail that represent each SCIO ............ 152 Table 7.12 List of actors associated with each business process ................................................ 152 Table 7.13 Detailed steps for Phase 4 of the SCM2 ..................................................................... 154 Table 7.14 Detailed steps for phase 5 of the SCM2 ..................................................................... 159 Table 7.15 Detailed steps for phase 6 of the SCM2 ..................................................................... 167 Table 7.16 Model components, definitions and examples (in the BeerCo development case) . 171 Table 7.17 Detailed steps for phase 7 of the SCM2 ..................................................................... 174 Table 7.18 Aligning the SCM2 to meet the requirements for an ‘effective’ model ..................... 178 Table 7.19 Meet the requirements of ‘good’ methodologies ..................................................... 180 Table 7.20 Meet the requirements for CM of supply chain problems ........................................ 181 Table 8.1 Statement of the supply problem (CoffeePotCo) ...................................................... 186 Table 8.2 Statement of each objective to be measured (CoffeePotCo) .................................... 188

13

Table 8.3 Statement of how each process represents each improvement (CoffeePotCo) ....... 189 Table 8.4 Promoted process elements and simplified inputs (CoffeePotCo) ............................ 192 Table 8.5 Candidate process elements promoted in each round (CoffeePotCo) ....................... 193 Table 8.6 Summary of the feasibility criteria to be examined ................................................... 195 Table 8.7 Summary of the utility criteria to be examined ......................................................... 196 Table 8.8 Key observations from an analysis of the information requirements for the SCM2 .. 198 Table 8.9 Key observations from an analysis of the information provided from the SCM2 ...... 199 Table 8.10 Evaluation of ‘facilitation’ when using SCOR ............................................................. 203 Table 8.11 Summary of the usability criteria to be examined .................................................... 205 Table 8.12 Opportunities to automate aspects of the SCM2 ...................................................... 207 Table 9.1 Research contribution made by this thesis................................................................ 211 Table 9.2 SCM2: Procedure and key concepts for SCM applications ......................................... 214 Table 9.3 Summary of issues for future testing ......................................................................... 223 Table 9.4 Revisiting Robinson (2006a; 2006b) issues in CM ..................................................... 226 Table A.1 Principle/observations when designing phase one ................................................... 251 Table A.2 Principle/observations made that included the design of phase two ....................... 252 Table A.3 Principle/observations made that influenced the design of phase three ................. 253 Table A.4 Principle/observations made that influenced the design of phase four ................... 254 Table A.5 Principle/observations when designing phase five .................................................... 255 Table A.6 Principle/observations when designing phase six ..................................................... 257 Table A.7 Principle/observations when designing phase seven ................................................ 258 Table D.1 Model components for ‘Retailer plan and place order’ (BeerCo development case) 266 Table D.2 Model components for ‘Wholesaler Receive and fulfil order’ (BeerCo development case) .................................................................................................................................... 267 Table G.1 AS-IS Scenario in CoffeePot Co validation case for the ‘Customer’ ........................... 271 Table G.2 AS-IS Scenario in CoffeePotCo validation case for the ‘Warehouse’ ......................... 272 Table G.3 AS-IS Scenario in CoffeePotCo validation case for the ‘Factory’ ................................ 273 Table G.4 TO-BE Scenario in CoffeePotCo validation case for the ‘Factory’ .............................. 274 Table H.1 Evaluation of how the SCM2 uses information ........................................................... 275 Table I.1 Issues for testing the ‘usability’ of the SCM2 ............................................................. 277

14

Chapter 1 Introduction Chapter one discusses the context of the research project for the development, refinement and

preliminary validation of a simulation conceptual modelling methodology for supply chain

management applications (termed the ‘SCM2’). It describes the background to the research,

research objectives, questions and programme to address each objective, justification for

research focus, main body of the thesis, and the extent of the scope and definitions used in the

research project.

The research is bounded within the ‘simulation’ literature with a focus on the ‘conceptual

modelling’ stage of a simulation project in the context of ‘SCM’ applications. The research

objectives and questions address the need to form a specification for, develop and refine and

initially validate the feasibility and utility of the SCM2 proposed in this thesis. A five stage research

programme is designed to realise the aims and objectives of this research and address each of the

questions posed. This includes reviewing existing conceptual modelling practices (stage I,

presented in chapter four), forming the specification for the SCM2 (stage II, presented in chapter

five), outlining the design for the SCM2 (stage III, presented in chapter six), detailing and refining

the design for the SCM2 (stage IV, presented in chapter seven) and a preliminary validation of the

SCM2 (stage V, presented in chapter 8). The research programme adopts an iterative

triangulation method to systematically iterate between extensive literature review, existing case

evidence and intuition. Three typical and complex supply problems are used to refine and

preliminarily validate the methodology.

1.1 Research background

The research focuses upon the creation of simulation conceptual models for supply chain

applications. The methodology is developed within the supply chain management discipline for

participants undertaking the conceptual modelling stage as part of a simulation project. This

focus is original and significant because the need for a greater understanding of conceptual

modelling is required; particularly the development of structured approaches, as no simulation

conceptual modelling methodologies exists in the SCM domain. Both the wider discipline and the

particular focus of this thesis are briefly discussed to provide some background to the project.

The origins of the use of the term ‘supply chain management’ (SCM) can be traced back to the

early 1980s (Houlihan, 1987); over the last three decades the prominence and importance of the

discipline has grown at an escalating rate. During this period, similar terms such as ‘network

sourcing’, ‘supply pipeline management’ and ‘value chain management’ have been subjects of

15

interest, for both theory and practice (Christopher, 2004; Hines, 1994; Lamming, 1996; Saunders,

1995, 1998; Croom, Romano and Giannakis, 2000).

There has also been some debate over whether supply chain management is itself a

distinguishable discipline in its own right (e.g. Croom et al., 2000; Harland, Lamming, Walker,

Phillips, Caldwell, Johnsen, Knight and Zheng, 2006). Harland et al., (2006) judged SCM to be an

emerging discipline, providing evidence that existing research contributions lack quality of

theoretical development, discussion and coherence. In relation to practice, there is widespread

agreement that SCM is critical to organisational performance (e.g. Tan, Kannan and Hardfield,

1999; Kannan and Tan, 2005; Li, Ragu-Nathan, B., Ragu-Nathan, T.S., and Subba-Roa, 2006).

Additionally as a field of study, it has gained significant momentum, as new opportunities exist to

develop new theories, concepts and tools that could be applied in practice.

Despite the popularity of the term ‘SCM’ both in academia and in practice there has been

considerable confusion as to its meaning (Mentzer, Dewitt, Keebler, Min, Nix, Smith and Zacharia,

2001). Some authors have defined SCM in operational terms involving the flow of materials and

products, some view it as a management philosophy and some view it in terms of a management

process (Tyndall, Gopal, Patsch and Kamauff 1998). Mentzer et al., (2001) reviewed, categorised

and synthesised a view of what constitutes SCM from definitions used in both research and

practice in order to reduce this ambiguity. Mentzer et al., (2001, pg. 4) contended that a supply

chain can be defined as 'a set of three or more entities (organisations or individuals) directly

involved in the upstream and downstream flows of products, services, finances, and/or

information from a source to a customer'. This definition is similar to Christopher’s (2004)

definition as it highlights the structure, linkages and flows in a supply chain. In relation to

Christopher (2004) he also highlights how processes and activities ‘add value’ to a product and

service. From a strategic management perspective, ‘value’ concerns what Tan, Kannan and

Hanfield, (1998) describes as the utilisation of resources and capabilities to build competitive

advantage. The term ‘supply strategy’ has also been suggested as a way to move SCM from a

predominantly operational domain (relating to the flow of material and information) to one that

also considers strategic aspects (Harland, Lamming and Cousins, 1999).

Simulation has been used as a method to evaluate the complexity of supply chain problems (e.g.

Ridall, Bennet and Tipi, 2000; Huang, Lau and Mak, 2003; Van der Zee and Van der Vorst, 2005). It

is regarded as the proper means for supporting decision making on supply chain design (Van der

Zee and Van der Vorst, 2005). One important component of a simulation modelling process is the

16

need to create a conceptual model. However it is the least understood aspect in the process

(Law, 1991; Robinson, 2004a; 2004b, 2008a; 2008b). The need to formulate the problem

precisely has appeared in all descriptions of how to conduct a simulation project (e.g. Shannon,

1975; Law and Kelton, 2000), although perhaps the first use of the term ‘model conceptualisation’

can be found in Musselman (1994). After this period the term and discussions of conceptual

modelling practice have become more common (e.g. Robinson and Bhatia, 1995; Balci, 1997; Law,

2003) and, more recently, some definitions have been offered (e.g. Banks, 1999; Robinson, 2004a;

2004b; 2008a; 2008b).

A simulation model in the context of evaluating supply chain problems can be defined using Pidd’s

(1998) definition. A simulation model for SCM applications is a representation of the supply

system, used to investigate possible improvements and the effect of these improvements in the

real world setting of the supply problem. The conceptual model is a non-software specific

description of the simulation model to be developed (Robinson, 2004a; 2004b). It describes the

supply chain problem in terms of the objective of the study, improvements selected to improve

performance within its defined supply setting, the content of the model and any assumptions and

simplifications incorporated into the model. More specifically, using Banks’ (1991) terms, the

content concerns the relationships between the components and structure of the supply system.

These are described in terms of the scope (the components and relationships that need to be

included in the model to define its structure) and detail necessary to represent the actual

practices to be modelled.

1.2 Research aims, objectives and programme

The aim of the research presented in this thesis is to:

“Develop, refine and preliminarily validate a methodology that utilises domain-knowledge combined with a procedure that can be followed to create a simulation conceptual model for SCM applications”

This aim is fulfilled by achieving three research objectives:

1. Objective One – Document a specification of the requirements for creating simulation

conceptual models for SCM applications

2. Objective Two - Develop and refine a methodology that can meet the specification of the

requirements for creating simulation conceptual models for SCM applications

3. Objective Three – Preliminarily validate the initial feasibility and utility of the

methodology to create simulation conceptual models for SCM applications

17

A five stage research programme has been designed which contributes to the attainment of each

of the research objectives noted previously. An iterative triangulation method is justified to

ground theory development using existing case applications. This method is used to apply the

SCM2 to typical and complex supply problems to firstly refine and secondly preliminarily validate

the procedure to be followed that incorporates the use of domain-knowledge. The process

iterates between case evidence, reviewed literature and intuition to develop knowledge prior to

rigorous testing so that the SCM2 can be extended into a cohesive theory (testing is noted as

further work).

The first objective identifies a specification of the requirements for a simulation conceptual

modelling methodology for SCM applications. To achieve this two research questions are posed:

1. How are simulation conceptual models created in the context of supply chain

applications? 2. What is the specification of a simulation conceptual modelling methodology for evaluating

supply chain problems?

These questions form the basis of stage I (Review of existing conceptual modelling practice,

discussed in chapter four) and stage II (Required specification for the SCM2 to be developed,

discussed in chapter five) of the research programme. A review of existing conceptual modelling

practice in the domain of SCM demonstrates the need for a methodology that can be followed for

SCM applications. Following on from this, a specification is detailed for an effective conceptual

model, characteristics of a good methodology, and the requirements for evaluating supply chain

problems.

The second objective develops and refines a methodology that can meet the specification of the

requirements for creating simulation conceptual models for SCM applications. To achieve this

objective, one research question is posed:

3. Can a simulation conceptual modelling methodology be developed to meet the required

specification?

This question forms the basis for stage III (outline design for the methodology, discussed in

chapter six) and stage IV (detailed and refined design for the SCM2, discussed in chapter seven) of

the research methodological programme. The methodology is grounded in existing conceptual

modelling practice and ten key concepts are identified to be incorporated into a general process

for conceptual modelling. The methodology is refined through the application of two typical and

18

complex supply chain development cases before the revised design is aligned to show that it

meets the specification of the requirements.

The third and final objective provides a preliminary validation of the initial feasibility and utility of

the methodology to create simulation conceptual models for SCM applications. To achieve this

objective, one research question is posed:

4. Can the methodology be followed (feasibility) and aid a user (utility) to create a simulation

conceptual model for a SCM application? This question forms the final stage, stage V (preliminary validation of the SCM2, discussed in

chapter eight) of the research methodological programme. This addresses two of Platts (1993)

criteria for testing a methodology, process, or framework. It is argued that both the feasibility

and utility of the methodology can be initially validated by applying it to a different supply chain

problem. The validation case is a supply chain problem which has been evaluated by a simulation

approach and published in the academic literature (see Taylor, Love, Weaver and Stone, 2008). It

is used to compare the actual practices that have been identified by the methodology with the

model components and interconnections that are included in the computer model. The validation

case is also used to suggest how the feasibility and utility of the methodology should be further

tested and how further work should include tests for its ‘usability’. The discussion also identifies

and considers some opportunities to develop a web-based application tool to improve the

accessibility and efficiency of the methodology.

1.3 Justification for the research focus

Effective SCM is critical to any organisation’s ability to compete effectively (Stewart, 1997), which

has led to organisation’s seeking ways to improve supply chain performance. The difficulty when

evaluating supply chain problems is that they are inherently complex and dynamic systems (e.g.

Davis, 1993; Levy, 1994; Beamon, 1998). Simulation is one approach that is often cited as a

method that can be used to evaluate complex and dynamic systems (e.g. Ridall et al., 2000; Huang

et al., 2003; Van der Zee and Van der Vorst, 2005); the extent of research that has used simulation

as a method to evaluate supply chain problems is great.

In a typical supply chain project there is one stage that is often regarded as the most important:

the process of creating a conceptual model (Law, 1991). Robinson (2008b) points out that there is

surprisingly very little written on the subject; except in Robinson’s (2004b) simulation text. Even

when looking at this text only a handful of pages are dedicated to the subject and in the wider

literature there is a distinct lack of research contributions. Research can be identified on

19

understanding the importance of ways of thinking of tackling a simulation problem (e.g. Nance,

1994; Robinson, 1994; Brooks and Tobias, 1996). This has yet to deliver structured approaches for

creating a conceptual model. Although some guiding principles, methods for simplifications, and

frameworks for completing the stage as part of a simulation project can be found. In an attempt

to remedy this situation a stream was organised at the Operational Research Society Simulation

Workshop in 2006. Robinson (2008b) noted that this stream represented the highest number of

concentrations of papers on this topic in comparison to previous journals or conference papers.

This was a major motivation for this research, particularly as the majority of work was at a

conceptual (early) stage. In addition the majority of contributions was based on manufacturing

problems and had not explicitly addressed the needs of SCM.

This thesis demonstrates that the complexity and dynamic behaviour inherent in supply chains

presents a different set of requirements. The problems are not confined to a single organisation

and the improvements that an evaluator may wish to experiment with are much wider and, on

the whole, different from manufacturing problems. This thesis also suggests ten key concepts

that could form the basis of a methodology for creating simulation conceptual models for SCM

applications. In particular, the research argues that there is a significant opportunity to utilise

domain knowledge from a published supply chain process reference model (e.g. Supply Chain

Council SCOR model) aligned with a general process for conceptual modelling.

The intention of the work is to enable relevant and significant advances for conceptual modelling

as an area that requires further research, practice and the teaching of simulation. The

methodology requires further work to enable an application to be developed that incorporates

the methodology, made accessible for potential users to benefit from. In addition to this primary

contribution a number of secondary contributions are suggested that should provide avenues for

further study and advancement.

1.4 Outline of the thesis

The thesis is organised into nine chapters and four main parts, as depicted in figure 1.1. These

parts include the introduction, development of the research aim, objectives and programme,

research programme implementation and conclusions.

20

• Chapter 1: Introduction to research projectIntroduction

• Chapter 2: Research issues in simulation conceptual modelling for SCM applications

• Chapter 3: Research programme for developing, refining and preliminary validating the SCM2

Development of research

aim, objectives and

programme

• Chapter 4: Stage I: Review of existing simulation conceptual modelling practice

• Chapter 5: Stage II: Forming the specification for the SCM2

• Chapter 6: Stage III: Outline design for the SCM2

• Chapter 7: Stage IV: Detailed and refined design for the SCM2

• Chapter 8: Stage V: Preliminary validation of the initial feasibility and utility of the SCM2

Research programme

implementation

• Chapter 9: Conclusions and future implications of the researchConclusion

Figure 1.1 Overview of the thesis structure and research programme

The contribution of the remaining chapters in this thesis can be summarised:

Chapter 2 Discusses the research issues in simulation conceptual modelling for SCM

applications. It demonstrates that there is a gap for the development of the SCM2

and that is both original and significant. The importance of evaluating supply

chain problems to improve organisational performance is discussed. This is

followed by highlighting the complexity of evaluating supply problems.

Simulation is argued as one major approach that can address the complexity of

supply chain problems. An aspect of a simulation project that is not well

understood but is of crucial importance is the process of conceptual modelling.

There are no guidelines available to follow in order to create a conceptual model

for SCM applications, therefore the development of a methodology is argued as a

way to address this need. The benefits to both research and practice are

identified.

21

Chapter 3 Presents an overview of the research programme and methods to address the

aim and objectives of the research project. The stages that should be included in

the programme are justified and suitable methods are identified for each stage.

Chapter 4 Presents the implementation of stage I of the research programme by reviewing

existing simulation conceptual modelling practice in the context of SCM

applications. The chapter establishes the need for the methodology.

Approaches to conceptual modelling are identified and reviewed to show that no

methodology exists that delivers the aim of this research. It also discusses the

problems encountered in a simulation project that could benefit from a greater

understanding and structured methods for conceptual modelling. The methods

of communicating and representing the conceptual model and how conceptual

models have been validated are identified as two aspects that warrant greater

discussion.

Chapter 5 Presents the implementation of stage II of the research programme by forming a

specification for the SCM2. The methodology is founded upon existing conceptual

modelling practice and the requirements for, an effective conceptual model, a

good methodology and for conceptual modelling within the domain of SCM. The

specification is detailed so that the methodology can be developed to meet the

requirements.

Chapter 6 Presents the implementation of stage III of the research programme by outlining

a design for the SCM2. The chapter brings together and suggests ten key concepts

from a review of the design issues for each of the requirements identified in

chapter five. The proposition developed in the chapter is that a procedure for

the SCM2 can utilise domain knowledge from a supply chain process operations

model to enable a more focused and efficient process.

Chapter 7 Presents the implementation of stage IV of the research programme by detailing

a developed and refined design for the SCM2. Two typical and representative

supply chain development cases are used to refine the methodology. The ten key

concepts identified in chapter six are incorporated into a procedure for the

methodology. Each of the phases is discussed in turn so that the specific steps,

information needs, participation requirements and points of entry can be

22

detailed. The chapter concludes by aligning the detailed design to demonstrate

that the specification presented in chapter five has been met.

Chapter 8 Presents the implementation of stage V of the research programme by

preliminarily validating the initial feasibility and utility of the SCM2 to a different

supply chain problem. The validation case is used to walkthrough the steps to

demonstrate that they can be followed to create a simulation conceptual model.

The validation only considers the phases up to the point that the actual practices

to be included in the model are detailed, after this point existing modelling

practice is adopted. It also enables a comparison between a successful computer

model, which has been published in the literature, to be compared to a list of

actual practices identified by the methodology. Issues for future testing are

discussed and an opportunity to simplify and automate aspects of the process in a

tool that utilises published domain knowledge is considered.

Chapter 9 Concludes the thesis and discusses the future implications for the research. It

details the primary and secondary contributions made by this thesis. The

research aim and objective is reviewed to demonstrate that they have been met

and that the research programme was both suitable and rigorous. Limitations of

the work are described and implications for further study are identified.

1.5 Delimitation of scope and definitions

The research focuses upon the creation of simulation conceptual models for supply chain

applications rather than conceptual modelling in general. The implication of this is that the

methodology presented in this thesis is intended for participants who are undertaking a

simulation project with a supply chain problem. The analysis and information provided by the

methodology would be different in other domains (e.g. manufacturing, service). Nevertheless,

outside this scope the research has many implications for the key concepts incorporated into the

methodology that could be applied in other domains (e.g. how to formulate the model boundary).

Within this scope there are a number of considerations that need to be raised:

1. Definition of a supply problem

2. What constitutes a simulation conceptual model for SCM applications

3. Limitations of the research programme

23

The term ‘supply problem’ is used to incorporate the improvements that have been selected to

improve performance for a given objective within the setting of the supply problem. This term is

used as it identifies that a supply problem can be made up of a range of improvements (e.g.

improve supply chain visibility), to achieve a range of supply chain performance measures (e.g.

responsiveness, cost) within the setting of the supply problem (e.g. linkages between suppliers

and customers). In relation to the latter, conceptual modelling involves formulating an

understanding of what should be included within the simulation study. This presents an issue of

determining only the necessary model components and interconnections that represent the

actual practices of the real world problem. The term should not be confused with the term supply

“chain”, or even “network”. A supply chain/network has a specific definition which includes the

‘entities directly involved in the upstream and downstream flows of products, services, finances,

and/or information from a source to the customer’ (Mentzer et al., 2001, pg. 4). This

demonstrates that the term ‘supply problem’ defines more than the structure and flows in a

supply system but also how it is to be improved and how performance will be measured.

The research is bounded within the ‘simulation’ literature with a focus on the ‘conceptual

modelling’ stage of a simulation project. Definitions do exist for conceptual modelling in general

but there is considerable debate into what is described by a simulation conceptual model

(discussed in section 2.1). The majority of the work in this thesis is underpinned by the major

advances made by Robinson, most notably in his 2004 text on ‘simulation practice and

application’ and associated publications. These have considered effective conceptual modelling

(Robinson, 1994) issues for conceptual modelling research and practice (2006a; 2006b; 2008a)

and the development of a general framework (Robinson, 2004a; 2004b; 2006a; 2006b) which has

until recently been illustrated (Robinson, 2008b). Robinson’s definition for a conceptual model is

adopted in this thesis and used to further a definition for what constitutes a methodology that

can be followed to create a conceptual model for SCM applications.

A conceptual model is defined as:

‘...a non-software specific description of the simulation model that is to be developed, describing the objectives, inputs, outputs, content, assumptions and simplifications of the model’

Robinson (2004b, pg. 65)

In the context of this thesis the methodology delivers:

‘A methodology that offers a prescribed procedure that guides the participants undertaking the conceptual modelling stage of a simulation project, to create a non-software specific description of the simulation model to be developed, in the context of SCM applications’

24

The definitions provide some useful distinctions that have shaped this research project. This

includes that the definitions view the process of conceptual modelling as independent from

particular simulation software. The intention of this research is to not be biased by any particular

software used by the researcher. However, when describing the model components a modeller

may have a particular simulation worldview (Pidd, 2004b; Owen, Love and Albores, 2008) which

will have a bearing on the way in which the computer model to be developed is described. For

this reason the methodology incorporates general terms and practice for describing the

components in the model. The implication of this is that only the original aspects of the

methodology are applied and tested.

The preliminary validation is used to illustrate the initial feasibility and the utility of the

methodology. The actual practices to be included in the computer model are compared to the

components and interconnections that form the design of the computer model presented in

Taylor et al., (2008). The supply problem evaluated in Taylor et al., (2008) is simulated using a

discrete-event simulation approach. The research notes to be able to generalise the feasibility

and utility of the methodology it would require further applications in different industrial contexts

and with actual participants. This would also involve testing the general usability of the

methodology.

1.6 Chapter summary

The aim of this research is to develop, refine and preliminarily validate the initial feasibility and

utility of a simulation conceptual modelling methodology for SCM applications. The research

objectives are designed to realise this aim. These include:

Documenting a specification of the requirements for creating simulation conceptual

models for SCM applications

Developing and refining a design of the methodology that meets the specification

Validating the initial feasibility and utility of the methodology.

The research focuses on creating conceptual models that describe how a supply problem can be

described so that a computer model can be developed. This is identified as an original and

significant area for research as no methodologies exist that can meet the research aim.

Particularly there is a need to develop structured approaches that can guide participants through

the process of conceptual modelling as part of a simulation project within the domain of SCM.

25

A five stage programme has been designed to achieve the aim and objectives set out in this thesis.

This includes a review of existing conceptual modelling practice (stage I, implemented in chapter

4), forming the specification for the SCM2 (stage II, implemented in chapter 5), outlining a design

for the SCM2 (stage III, implemented in chapter 6), detailing and refining the design of the SCM2

(stage IV, implemented in chapter 7) and a preliminary test of the SCM2 (stage V, implemented in

chapter 8). An iterative triangulation research approach is adopted to iterate between an

extensive literature review, application of the methodology to three representative and typical

supply chain problems and intuition. Two existing cases are used in the design and refinement

stages, and one to illustrate the initial feasibility and utility of the methodology.

The methodology is developed for the purpose of creating a conceptual model for supply chain

applications, not for general purposes. The preliminary validation is used to illustrate that the

actual practices to be represented in the computer model can be derived by following the steps as

laid down in the methodology. The components and relationships between them, that form the

description of the computer model developed in Taylor et al., (2008) are compared to the actual

practices described by following the methodology to discuss any similarities, omissions or

significant differences. Future testing is outlined in this thesis to improve the validity and wider

applicability of the methodology in different applications and involvement of potential users.

26

Chapter 2 Research issues in conceptual modelling for SCM

applications

This chapter identifies and discusses the relevant research issues in conceptual modelling for SCM

applications. The aim is to demonstrate that a gap exists for a simulation conceptual modelling

methodology for SCM applications that is original and significant. This gap is filled by developing

and preliminary validating a simulation conceptual modelling methodology for SCM applications.

This chapter is structured to demonstrate this gap by considering the following research issues:

Scope and selection of contributions in literature review (section 2.1) – States that the

research is bounded within the simulation conceptual modeling literature with a

particular focus on SCM applications

Importance of evaluating supply chain problems (section 2.2) - Discusses the importance

of evaluating supply problems as one significant way to improve performance

Complexity of evaluating supply chain problems (section 2.3) – Demonstrates that

evaluating supply chain problems is extremely complex

Role of simulation to evaluate supply problems (section 2.4) – Identifies that simulation

is one approach that can address the complexity of supply problems. The range of

approaches used in simulation is overwhelming and the amount of research using

simulation is great.

Role of conceptual modelling in simulation projects (section 2.5) - Identifying that

conceptual modelling is an important and critical aspect in a simulation modelling

process.

Understanding of conceptual modelling for SCM applications (section 2.6) -

Demonstrating that conceptual modelling is the least understood aspect of a simulation

project and no guidelines exist for SCM applications. A gap exists in the literature that can

be filled by the aim and focus of this thesis.

Usefulness of a conceptual modelling methodology for SCM applications (section 2.7) -

Proposes that a methodology would be a useful way to guide participants through a

complex supply problem to describe how it could be modelled

Benefits of developing a conceptual modelling methodology for SCM applications

(section 2.8) - Showing that a methodology would yield benefits to practitioner users

27

2.1 Scope and selection of contributions in literature review

The scope of the literature review gathers contributions on ‘conceptual modelling’ for ‘simulation’

purposes within the domain of ‘SCM applications’. The term ‘conceptual modelling’ has however

been used much more widely in the general management literature. In general a conceptual

model is a ‘set of concepts, with or without propositions, used to represent or describe (but not

explain) an event, object, or process’ (Meredith, 1993). The description is also used as a means of

communicating a set of requirements between stakeholders involved in a project. Using this

general definition there are a number of application areas that have used the term ‘conceptual

modelling’; examples include:

Architecture, engineering and construction – e.g. Krause, Luddeman and Striepe (1995)

for industrial design; Turk (2001) on conceptual product modeling; Shane (2005) on

conceptual modeling in urban design and city theory

Business management – e.g. Carrol (1979) for conceptual modeling of corporate

performance and Parasuraman (1985) describe a conceptual model of service quality

Computing and web engineering – e.g. Thompson (1991) personal computer utilisation

Information systems development – e.g. Olive (2007) for conceptual modelling of

information systems; Mendes et al., (2006) for conceptual modelling of web applications

and Schewe and Thalheim (2005) for conceptual modelling of web information systems

Research methods – e.g. Meredith (1993) discuss theory building through conceptual

methods; Hair et al., (2007) discuss conceptualisation and research design in general.

There are three notable differences that distinguish ‘simulation conceptual modelling’ from the

application areas noted above. This includes the domain to be represented, scope and level of

abstraction and the process to be followed to create a conceptual model. For instance, an

architectural conceptual model could include a model replica of a bridge to a particular scale. In

simulation conceptual modeling the requirement is to describe the computer model to be built.

This includes the inputs, outputs, content (involves determining the scope and level of detail),

assumptions and simplifications (Robinson, 2004). The process to identify these requirements

moves from a problem situation, through model requirements to a definition of what is going to

be modeled and how it is to be done (Robinson, 2008a). A procedure for simulation conceptual

modeling must provide guidelines on how this is to be achieved, which is heavily dependent upon

the domain (e.g. supply chain) being represented.

One particular approach that has been used in the context of simulation conceptual modeling

includes Checkland (1981) ‘soft system methodology’ (SSM) to determine the simulation study

28

objectives (see Kotiadis, 2007). SSM includes a stage for building a conceptual model to describe

activities and processes from a root definition (problem statement). In this instance, the

conceptual model is represented as a rich picture that captures a human system of issues, actors,

problems, processes, relationships, conflicts and motivations. Kotiadis (2007) argues that the

study objectives are the most critical part of a simulation study which benefits from using SSM as

a problem structuring method. This is however, only the first step of the process of creating a

simulation conceptual model. SSM does not explicitly guide a modeller through the decisions

necessary to determine the scope and level of detail (model content) or even incorporate any

necessary assumptions and simplifications into the model design (e.g. specific techniques such as

aggregate model components).

The literature review selection criterion has focused upon conceptual modelling for the purposes

of simulation, particularly in the SCM domain using the terms shown in table 2.1. It was also

necessary to include a wider search for operations management research as this is often used as

an umbrella term. The key words ‘supply chain’ were adopted over ‘supply chain management’ to

provide a more exhaustive list. Secondly, more specific searches were undertaken to establish a

more focused body of knowledge that discusses ‘conceptual modelling’. The term ‘conceptual

model’ was also searched recognising that ‘conceptual modelling’ relates to the process that

creates a ‘conceptual model’. The literature was searched in four primary academic databases

used in management research along with the WinterSim conference (annual simulation

conference) and a dedicated Workshop that addressed a call for more research into simulation

conceptual modelling (Operational Research Society Simulation Workshop, 2006). The

conference contributions accounted for some of the earlier and latest contributions on simulation

conceptual modeling.

29

Table 2.1 Selection of contributions that meet search terms in each academic database

Academic literature database

Search terms

Simulation AND Supply

chain

Simulation AND

Operation

Simulation AND

“conceptual modelling”1

Simulation AND

“conceptual modelling”

AND operation

Simulation AND

“conceptual modelling” AND supply

chain

Simulation AND

“Conceptual model” AND

Operation

Simulation AND

“Conceptual model” AND

“Supply chain”

ABI/Inform Global

Proquest 499 226 11 0 1 9 1

EBSCO (Business

Source Complete)

408 313 9 2 2 12 1

Emerald 88 50 7 1 1 2 1

Science Direct

45 56 161 19 1 44 17

Informs online2

727 1,720 72 32 16 131 60

2.2 Importance of evaluating supply chain problems

Managing supply-chain operations is critical to any company’s ability to compete effectively

(Stewart, 1997). Over the past two decades there has been an acceleration of interest in the

analysis, management and control of supply chains (e.g. Gattorna and Walters, 1996; Beamon,

1998; Petrovic, 2001; Christopher and Towill, 2002; Persson and Olhager, 2002; Shepherd and

Gunter, 2006; Gunasekaran and Ngai, 2008; Fildes, Goodwin, Lawrence and Nickolopoulos, 2009).

Whether it is by coordination of activities through the supply chain or by recognising the

capabilities of immediate suppliers, understanding supply chain dynamics has a significant impact

on performance (e.g. Tan et al., 1999; Kannan and Tan, 2005; Li et al., 2006).

Supply chain management represents one of the most significant paradigm shifts of modern

business management by recognising that individual businesses no longer compete as solely

autonomous entities, but rather as supply chains (Christopher, 1992, 1998; Lambert and Cooper,

2000; Spekman, Spear and Kamauff, 2002; Cousins and Spekman, 2003; Chen and Paulraj, 2004).

This has led both researchers and practitioners, to consider improvements and practices outside

the boundaries of an organisation (with suppliers and customers in a network, chain or

partnership) and ways to effectively manage and control the supply chain. The term ‘supply

strategy’, coined by Harland (1997), has been one significant attempt to move away from a

traditional view of the flows between suppliers and customers to one that considers a more

holistic approach to managing the entire supply network. As a field of study and practice there

has been a whole host of other attempts to move research from an embryonic stage (suggested

1 UK spelling is ‘modelling’ while in US dictionary it is spelt ‘modeling’; accounted for in the search

2 Wintersim and Operational Research Society Simulation Workshop (accessed via www.informs-sim.org)

30

by Handfield and Melnyk, 1998; Chen and Paulraj, 2004); to one that has more scientific

development and recognition as a discipline in its own right (Croom et al., 2000).

There has also been a considerable interest to describe supply chain management, its activities,

practices and ways to measure supply chain performance. In earlier years this was a distinct issue

in SCM (New, 1997; Tan, 2001) but has been dramatically improved with recent research

contributions. Most notably the advent of supply chain process frameworks developed by the

Global Supply Chain Forum (e.g. Cooper, Lambert and Pagh, 1997; Croxton, Garcia-Dastugue,

Lambert and Rogers, 2001; Lambert et al., 2005) and the Supply Chain Council (SCOR v.9, 2008)

with considerable input from industry may have been a catalyst. These frameworks have been

used to describe, analyse and evaluate improvements to a supply system in order to improve

decision-making on ways to improve supply chain performance (e.g. Arns, Fischer, Kemper and

Tepper, 2002; Bolstorff and Rosenbaum, 2003; Wang, Huang and Dismukes, 2004; Ball, Love and

Albores, 2008; Persson and Araldi, 2009).

The ability to evaluate the potential performance of supply chain opportunities is a critical

component of the supply chain improvement process. The challenge companies’ face is how best

to evaluate the potential of the host of supply chain improvement options that could be pursued

(Weaver, Love and Albores, 2006; 2007). Many of these improvement options have been

discussed in the literature (e.g. Supply Chain Council 2008; Van der Vorst and Beulens 2002;

Christopher, 1998; Berry et al., 1994). The fact that the Supply Chain Council suggests 420

different improvement options, demonstrates the considerable scope of the evaluation challenge.

Even when this number is reduced (e.g. Van der Vorst and Beulens (2002) presents a generic list

of 21 supply chain redesign options) it still presents a challenge to identify the most suitable

options based on the improvements in performance an organisation would realise.

Companies have far too often attempted to optimise their own value chains, without considering

the effect of these decisions on their suppliers or customers (Chopra and Meindl, 2004). For

instance, Cooper et al., (1997) have shown that sub-optimisation of a company’s own

performance rather than optimising the performance of the entire supply network, by integrating

its goals and activities with other organisations, can destroy value-creating opportunities.

Approaches (e.g. methods, frameworks, methodologies) that could aid in the process of

evaluating the value-creating potential of implementing alternative supply chain improvements

for an organisation and its members in a supply network would be useful. They could help to

31

maximise an organisation’s performance and the benefits received up (towards the ultimate

customer) and down the supply chain.

2.3 Complexity of evaluating supply chain problems

A definition of a supply system was offered in section 1.1. It recognised that the entities comprise

a number of actor (or roles, facilities) that make up the structure of the supply and demand chain

in which an organisation (e.g. manufacturing, retail or third sector) sits between. The complexity

of the supply chain arises from the number of echelons in the chain and the number of actors in

each echelon (Beamon, 1998).

The supply system can vary in complexity (e.g. size). Harland (1997) identified different levels of

supply, consisting of supply within the boundary of the firm (a process view), supply in dyadic

relationships, supply in an inter-organisational chain and supply in an inter-organisational

network, each of these levels involve different degrees of complexity. The complexity is also

compounded by the way in which actors within a dyad, chain or network can interact. As Levy

(1994) points out that the interactions are strategic in sense as a decision made by one actor take

into account anticipated reactions by others, thus it reflects recognition of interdependence. This

highlights that inter-organisation behaviour can also increase the complexity of a supply system

(e.g. interconnectedness between actors).

Over the years the research and practice of supply chain management has grown in meaning

through what Harland et al., (1999) describes as an externalisation beyond the boundary of the

organisation. Traditionally purchasing and supply management has been viewed as a firm-based

set of activities dealing with transactions between customer and supplier relationships (Baily and

Farmer, 1985). Later work in the 1980s attempted to elevate the purchasing function from being

considered operational and clerical, to a strategic level (e.g. Spekman, 1981; Caddick and Dale,

1987). A supply strategy involves more than just material, transaction and information flow, it

should take more of a holistic approach to managing the entire supply network (Harland et al,

1999). Harland et al., (1999) further points out that this would include aspects such as

interrelationships between organisational roles, network configurations, governance, integration

and collaboration.

As part of developing a supply strategy an organisation will adopt and implement one or many of

the various supply chain improvement options, within the boundaries of the organisation and

between suppliers and customers within the supply network. A supply problem is therefore made

32

up of these selected supply chain improvements, to achieve a supply chain objective, within the

supply setting that is specific to the actual organisation undertaking a study. Evaluating supply

problems is inherently complex and presents challenges in terms of the scope and level of detail

in which they should be analysed (Albores, et al., 2006; Weaver, et al., 2006). Owing to, for

example, a great variety of policies, conflicting objectives, and the inherent uncertainty of the

business environment, this is not an easy task (Alfieri & Brandimarte, 1997).

2.4 Role of simulation to evaluate supply chain problems

Simulation has often been cited as a method that could present the greatest potential in studying

supply chain as its complexity obstructs analytical evaluation (e.g. Ridall et al., 2000, Huang et al.,

2003, Van der Zee and Van der Vorst, 2005). It is often regarded as the proper means for

supporting decision making on supply chain design (Van der Zee and Van der Vorst, 2005). One

reason for this is that it may be used to support the quantification of the benefits resulting from

supply chain management (Kleijnen, 2005).

A simulation model is a representation of the system of interest, used to investigate possible

improvements in the real system, or to discover the effect of different policies on that system

(Pidd, 1998). In this context, the system is a supply chain or network and simulation is used to

evaluate the impact of different sets of supply chain improvements on the potential performance

of that system within its supply setting.

The benefits of using simulation as a means to evaluate supply chain problems have often been

cited. These include that simulation is the only approach that can holistically model the supply

chain (Tang, Nelson, Benton, Love, Albores, Ball, MacBryde, Boughton and Drake, 2004) and can

handle stochastic properties (Hae Lee, Cho, Kim and Kim, 2002; Persson and Olhager, 2002). This

is because it can be used to understand the overall supply chain process and characteristics using

graphics/animation (i.e. model elements and relationships), able to capture system dynamics and

facilitate decision-making by minimising the risk of making changes without fully understand the

impact of various alternatives on performance (Chang and Makatsoris, 2001; Van der Zee and Van

der Vorst, 2005). For instance, simulation is good for modelling the impact of variation such as

forecast error, supplier reliability and quality variance (Biswas and Narahari, 2004). A classic

example of understanding the effect of dynamic behaviour (e.g. process delays, lead times,

planning policies) in the amplification of demand signal, often known as the ‘bullwhip effect’ first

described by Forrester (1961).

33

2.4.1 Range of approaches used in simulation

The range of approaches used in supply chain simulation is overwhelming. Van der Zee and Van

der Vorst (2005) point out that in the past decade, a large number of simulation tools for supply

chain analysis have been developed internally (e.g. CSCAT in Ingalls and Kasales, 1999),

commercially (e.g. e-SCOR in Barnett and Miller, 2000; Albores et al., 2006), or concern

applications of general-purpose simulation languages (e.g. Arena in both Kelton, Sadowski and

Sadowski, 1998 and in Persson and Araldi, 2009).

There are a number of classifications of both modelling and simulation approaches suggested in

the SCM literature (e.g. Hicks, 1997; Beamon, 1998; Min and Zhou, 2002; Kim, Tannock, Byrne,

Cao and Er, 2004; Kleijnen, 2005; Weaver et al., 2006; Owen et al., 2008). Min and Zhou (2002)

present a detailed taxonomy of modelling and simulation techniques building upon previous work

by Beamon (1998). Kim et al., (2004) used Min and Zhou’s (2002) taxonomy to review techniques

for modelling supply chain in an extended enterprise, although they focused upon supply chain

management software and how these might be selected.

A study by Kleijnen (2005) provides a more specific survey of supply chain simulation tools and

techniques and a discussion of some methodological issues. Kleijnen (2005) found that there are

four main simulation types for supply chain management: spreadsheet simulation, system

dynamics, discrete-event and business games. On the other hand a discussion by Owen, et al.,

(2008) did not include spreadsheet simulation or business games but detailed how agent based

modelling is an emerging approach for evaluating supply chain problems. In more recent years,

new tools and techniques have been made available commercially largely due to the rise in

popularity of the SCOR process reference model. These have predominantly focused upon DES

(e.g. Gensym eSCOR; see Barnett and Miller, 2000; Albores et al., 2006; Persson and Araldi, 2009)

and adding simulation capabilities to existing static process modelling enterprise management

suites (e.g. Mote Carlo capabilities in Proforma and Aris process enterprise modelling suites; see

Poluha, 2007).

In relation to DES tools, these can be distinguished into identifiable classes that include process,

enterprise, manufacturing and supply chain specific simulation tools or techniques. Albores et al.,

(2006) and Weaver et al., (2007) showed that each of these classes have different competences

when evaluating supply chain problems. It is important to distinguish these as tools specific to

supply chain management are emerging, while a lot of research is conducted using existing

process (e.g. Process 2000 used in Benton, 2009), enterprise (e.g. suggested by Tang et al., 2004)

34

and manufacturing led packages (e.g. Witness used in Albores et al, 2006; Arena in Persson and

Araldi, 2009) which have been established for many years.

Figure 2.1 presents a classification of the different simulation approaches in light of the above

discussion.

Figure 2.1 Classification of supply chain simulation approaches Source: Synthesised and extended from past contributions by Beamon (1998); Min and Zhou (2002) and Kleijnen (2005); Albores et al., 2006; Weaver et al., 2007; Owen et al., (2008)

2.4.2 Extent and usage of simulation for research

The amount of research to evaluate supply problems using simulation approaches is great. It is

evident that simulation is not only a useful tool for evaluating supply problems, but has been

extensively used in the literature for research purposes. Table 2.2 lists each of the approaches

identified in section 2.3.3 and shows representative examples of the approaches being used

specifically for SCM applications. The majority of examples that could be identified used discrete-

event approaches, followed by system dynamic and some recent examples of multi-agent based

modelling. The approaches are described in this section in the context of how they have been

used to analyse supply problems.

Supply chain simulation approaches

Spreadsheet simulation

System dynamics (SD)

Multi-agent based simulation modelling

Discrete-event (DES)

Business process DES

Manufacturing wide DES

Supply chain wide DES

Enterprise wide DES

Business games

35

Table 2.2 Classification of simulation approaches Simulation Approach Use in SCM research

Spreadsheet simulation Sounderpandian, 1989; Chwif, Barretto, Saliby, 2002; Disney and Towill, (2003a; 2003b)

System dynamics (SD) Forrester, 1961; Towill, 1996a; 1996b; Ashayeri and Keij, 1998; Beamon, 1998; Angerhofer and Angelidis, 2000; Van der Pol and Akkermans, 2000; Otto and Kotzab, 2003; Spengler and Schroter, 2003; Ge, Yang, Proudlove, Spring 2004; Higuchi and Troutt, 2004; Fiala, 2005

Multi-agent based modelling (MABM)

Swaminathan, Smith, Sadeh, 1998; Gjerdrum, Shah, Papageorgiou, 2001; Lau, Wong, Pun, Chin, 2003; Cavalieri, Cesarotti, Introna, 2003; Lou, Zhou, Chen, Ai, 2004; Van der Zee, Van der Vorst, 2005; Datta, Christopher, Allen, 2007.

Discrete-event

simulation (DES)

Business process DES

Tumay, 1995; Chang and Makatsoris, 2001; Albores, Ball and MacBryde, 2002; Ball, Albores and Macbryde, 2004; Reiner, 2005; Melao and Pidd, 2006.

Manufacturing wide DES

Some supply chain problems have been evaluated using manufacturing-wide DES a review by Albores et al., (2006) considers their functionality. Other sources include: Lee and Lau, 1999); Ingalls and Kasales, 1999; Miller and Pegden, 2000; Taylor, Robinson and Ladbrook, 2003; Greasley, 2006.

Supply chain wide DES

Towill, 1991; Towill, Naim, Wikner, 1992; Wikner, Towill, Naim, 1991; Bhaskaran,1998; Petrovic, Roy and Petrovic, 1998; Chang and Makatsoris, 2001; Petrovic, 2001); Persson and Olhager, 2002; Huang and Gangopaghyay, 2004; Chan and Chan, 2005; Holweg, et al., 2005; Manzini et al., 2005; Truong and Azadivar, 2005; van der Zee and van der Vorst, 2005; Bandinelli et al., 2006; Iannoni and Morabito, 2006. Some applications specifically use SCOR e.g. Barnett and Miller, 2000, Hermann, Lin, Pundoor, 2003; Persson and Araldi, 2009. Albores et al., 2006 includes some detail to draw logical conclusions.

Enterprise wide DES

The merits of developing enterprise DES was discussed in Tang et al, 2004 but it was difficult to find examples in a supply chain context.

Business games Kleijnen, 1980; Kleijnen and Smits, 2003; strategic games i.e. beer game (e.g. Sterman, 2000; Sodhi, 2001; Simchi-Levi, Kaminsky and Simchi-Levi, 2003; operational games (e.g. Riis, Smeds and Landeghem, 2000)

2.4.2.1 Spreadsheet simulation

Spreadsheets are often too simple and unrealistic (Kleijnen, 2005) however they are widely used

for corporate modelling (Plane, 1997; Powell, 1997). Smith (2003) analysed a number of supply

chain scenarios showing that spreadsheets can typically be used for static, average analysis to

compute basic time varying conditions. Disney and Towill (2003a; 2003b) have used a

spreadsheet to model vendor managed inventory (VMI) in a supply chain. To improve the

capability of spreadsheet simulation linear and non-linear optimisers as well as Monte Carlo

simulation add-ins (e.g. @Risk and Crystal ball) have been developed (Powell, 1997).

2.4.2.2 System dynamics (SD)

System dynamics (SD) is another approach to model supply chains and achieve significant

performance improvement. It is an approach that is holistic and can accommodate the real world

(Towill, 1996b). It focuses upon the way in which system structures affect system behaviour at a

more macroscopic level, so it is less concerned with detail unlike DES (Pidd, 2004a; 2004b). SD

views companies as a system with six types of flows (materials, goods, personnel, money, orders

and information; output flows such as fill rates and average WIP and stocks (e.g. WIP at a given

point of time). SD assumes that managerial control is realised through the changing of state

variables (e.g. production and sales rates), which change flows, and hence stocks (Kleijnen, 2005).

The fundamental assumption in system dynamics is that behaviour is a result of structures – both

36

inside and in its environment (Pidd, 2004a; 2004b). This includes the feedback loops and delays

that are present in the system being observed.

It was Forrester (1961) who developed industrial dynamics, which he later coined ‘system

dynamics’. He studied a four link supply chain which included a retailer, wholesaler, distributor

and factory. His study examined how the links within the supply chain react to deviations between

actual and target inventories. Forrester (1961) found ‘common sense’ strategies may amplify

fluctuations in the demand of final customers, up in the supply chain. Further work has focused

on identifying this amplification as one of the bullwhip effects (e.g. Lee et al., 1997a; 1997b;

Disney and Towill, 2003a; 2003b). Other examples include supply chain re-engineering (Berry et

al, 1994; Towill, 1996a), information sharing (e.g. Fiala, 2005), time compression (Towill, 1996b)

and demand volatility in the supply chain (Anderson, Fine and Parker, 2000).

2.4.2.3 Business games

Business games are used to allow users (e.g. managers, students etc.,) to operate a simulated

‘real’ world system in its environment. Business games can be either strategic in nature or focus

on operational issues (Kleijnen, 2005). One of the advantages of business games is that human

behaviour (i.e. the decisions made by a user) can be evaluated on the impact of the simulated

system. Games have been used widely for educational purposes including in OM (e.g. Riis et al.,

2000) and SCM (e.g. Sterman, 1992; Anderson and Morrice, 2000; Kaminsky and Simchi-Levi,

1998) and for research purposes has focused primarily on the Beer Game (e.g. Mason-Jones and

Towill, 1997; Kimbrough, Wu and Zhong, 2002; Hieber and Hartel, 2003), which is one case used

to develop and refine the SCM2.

2.4.2.4 Multi-agent based modeling (MABM)

Multi-agent based modelling (MABM) is an emerging tool, especially when compared to the use

of SD and DES models. This may be due to a lack of a consistent set of definitions for key concepts

such as what an agent actually is, as well as a philosophy of its application (Schieritz and Milling,

2003; Borschev and Filipov, 2004; Owen et al., 2008). MABM models systems comprised of

autonomous, interacting agents such as agent behaviour in supply chains (Macal et al., 2005).

Swaminathan et al., (1998) identify different agents (i.e. manufacturers, transportation, suppliers,

distribution centres, retailers and end-customers) in a supply chain context and provide each

agent with an ability to use a subset of control elements. The control elements are used to help

in decision making at the agent level by utilising various policies (e.g. inventory, just-in-time

release and routing algorithms) for demand, supply, information and materials control within the

supply chain (Swaminathan et al., 1998). Applications of MABM include examining the behaviour

37

of entities in the system and their relationships such as studying the dynamics of supply chain

competition (e.g. Akkermans, 2001; Allwood and Lee, 2005) and product allocation and

scheduling (Kaihara, 2003).

2.4.2.5 Discrete event simulation (DES)

Discrete-event simulation is one of the most popular modelling techniques (Robinson, 2005). It

employs a next-event technique to control the behaviour of the model (Pidd, 2004a; 2004b). The

DES method has been used for over 50 years, with an array of software packages and successful

applications reported (Taylor and Robinson, 2006). Kleinjen (2005) notes that DES has two

distinct characteristics: it represents individual events (e.g. arrival of an individual customer order)

and it incorporates uncertainties (e.g. customer orders arrive at random points in time). SD on

the other hand has a more aggregated view including flows and most SD models do not have

randomness, yet SD models behaviour remains counter-intuitive because of the non-linear

feedback loops (Kleinjen, 2005). Owen et al., (2008) adds that the most fundamental difference

between SD and DES is the treatment of time, which is continuous in SD and discrete in DES.

Banks, Buckley, Jain, Lendermann, (2002) surveyed a number of simulation studies in SCM

conducted at IBM and Virtual Logistics. They discuss both strategic and operational uses of DES,

distributed SCM simulation and commercial packages for SCM simulation. A more comprehensive

literature review of applications of DES in a supply chain context has been discussed by Terzi and

Cavalieri (2004). They find that DES has been applied across a range of objectives including supply

network design, strategic decision support and analysis of supply chain processes.

Table 2.2 demonstrates that DES in a supply chain context have used business process DES; using

existing manufacturing-wide DES and specific supply chain wide tools and techniques.

Additionally an enterprise simulator which includes true financial evaluation across the supply

chain has been discussed in the literature (e.g. Tang et al., 2004; Ball et al., 2008). Ball et al.,

(2004) suggested the most comprehensive approaches currently available are domain specific;

these include those based on SCOR (e.g. Gensym eSCOR in Barnett and Miller, 2000; Persson and

Araldi, 2009) and the IBM Supply Chain Analyser (Bagchi, Buckley, Ettl and Lin, 1998).

2.5 Role of conceptual modelling in simulation projects

This section considers the role of conceptual modelling in simulation projects, which is the

particular focus of this thesis. The previous discussions have demonstrated that evaluating supply

problems is important and argued that one approach which is used extensively to evaluate their

38

potential includes simulation. Even outside of the domain of SCM, simulation is used widely and a

lot has been written on how to undertake a simulation project including its stages, some

approaches and practices have been suggested. One particular stage that is fundamental in all

simulation projects but little is written on the subject, involves the process of conceptual

modelling. With all the research and extensive use of simulation it is surprising that conceptual

modelling as an area of study has until recently not been researched in much detail. This section

considers the following arguments:

Importance of conceptual modelling in a simulation project (section 2.5.1)

Key debates in conceptual modelling that could be addressed by research (section 2.5.2)

Definition of what constitutes a conceptual model for SCM applications (section 2.5.3)

2.5.1 Importance of conceptual modelling in a simulation project

A simulation project is a process of interpretive, developmental, and analytical steps (Pritsker,

Sigal, and Hammesfahr, 1989; Law and Kelton, 1991; Musselman, 1994; Banks, Carson, Nelson

and Nicol, 2005). Musselman (1994) notes that these steps, which are intrinsic to all simulation

projects, generally include problem formulation, model conceptualisation, data collection, model

building, verification, validation, analysis, documentation and implementation.

Conceptual modelling is one step of a simulation project, which sits between the problem has

been formulated and the development of the computer model. The conceptual model is derived

from an understanding of the problem situation in the real world (Robinson, 2008a). It is an

abstraction of the real-world system under investigation that concerns the relationships between

the components and structure of the system (Banks, 1999). It is from this description that a

computer model can be coded and built.

Proper development of the conceptual model is critical to the success of a simulation project

(Pace, 2000a; 2000b). This is because the explicit statements of assumptions and detailed

descriptions of the relationships included in the conceptual model ensure that the model

develops in accordance with the problem statement (Manuj, Mentzer and Bowers, 2009). In

addition to this the documentation provided from the conceptual model stage can be used to

validate that the problem is “reasonable” for the intended purpose of the model (Sargent, 2005;

2008).

2.5.2 Key debates around the nature of conceptual modelling

In general, the notion of conceptual modelling, as expressed in the simulation and modelling

literature is ‘vague and ill-defined, with varying interpretations as to its meaning’ (Robinson,

39

2008a, pg. 280). Robinson (2008a) does however attempt to identify the key facets of conceptual

modelling, but notes that there is no complete agreement, these include:

Conceptual modelling is about moving from a problem situation, through model

requirements to a definition of what is going to be modelled and how

Conceptual modelling is iterative and repetitive, with the model being continually revised

throughout a modelling study

The conceptual model is a simplified representation of the real system

The conceptual model is independent of the model code or software (while model design

includes both the conceptual model and the design of the code) (first cited in Fishwick,

1995)

The perspective of the client and the modeller are both important in conceptual modeling

There is little agreement and not much discussion on defining a conceptual model. There is

however a widespread understanding that all simulation models are simplifications of reality

(Zeigler, 1976). It is at the conceptual modeling stage that the issue of how to abstract an

appropriate simplification of reality is made (Pidd, 2003). More specifically, Pace (2000a; 2000b)

states a conceptual model as a simulation developer’s way of translating modelling requirements

(what is to be represented by the simulation) into a detailed design framework (how it is to be

done), from which the software specific requirements (e.g. hardware, systems/equipments) that

will make up the simulation can be built. This presents a key question, of what is a definition of a

conceptual model in the context of evaluating supply chain problems (addressed in section 2.5.3).

There is agreement that the early stages of a modelling study are not just visited once (e.g. Balci,

1994; Willemain, 1995). It is an iterative process that is not only continuously revised during the

conceptual modelling phase but also in the life-cycle of the simulation project. Robinson (2008a;

2008b) supports this view by suggesting that conceptual modelling is not a one-off process, but

one that is repeated and refined a number of times during a simulation study. This presents two

issues: firstly, when to exit from the conceptual modelling stage and, secondly revising the

conceptual model during the implementation of the computer model. These issues have not

been discussed in the literature (except descriptions of the qualities for a conceptual model) but

are critical to a conceptual modelling methodology. For instance a conceptual model should

minimise the risk of building an inaccurate and non-credible computer model. Therefore,

iteration is fundamental in the conceptual modelling stage and, although iteration may be

necessary in later stages, it is less desirable and may demonstrate weaknesses in the conceptual

model described, or even, how it was created.

40

Another key facet includes the independence of the modelling requirement from one that is

skewed by the software requirements and capabilities. Once the conceptual model is defined,

Fishwick (1995) suggests it can then be refined into a more concrete executable model.

Therefore, the conceptual model is separate from model execution and, as Robinson (2008a)

highlights, is not concerned with how the computer-based model is coded. The modeller uses the

conceptual model to detail how it is to be implemented (Pace, 2000a; 2000b) with a particular

modelling approach (e.g. DEDS, SD) or, more specifically, tool or technique (e.g. Simul8, Process

2000). This is an important consideration as a simulation approach or even a tool or technique

may shape and affect the way in which a supply problem is to be represented. This is counter

intuitive to the aim of a conceptual model that represents actual practice in the simplest and most

accurate way.

The last consideration presented by Robinson (2008a) is how both the perspective of the modeller

and client needs to be reflected in the conceptual model. The end result is an agreement

between the modeller and the client of what the simulation model needs to include and do in

order to accurately represent the supply problem in the most suitable way. In the process the

modeller needs to extract from the client the actual practices in the ‘real system’ and determine

how they are to be modelled. This interpretation is a challenge and will require a series of

iterations based upon interactions between the client and the modeller. The relationship and role

between the client and modeller has not been widely discussed (except in Robinson, 2008a) and

the role of domain specific knowledge needed in the process of conceptual modelling. This is

addressed in later chapters explicitly as a key opportunity in the developing of a SCM2.

2.5.3 Defining conceptual modelling for supply chain problems

The key debates surrounding the nature of conceptual modelling provide some insights into what

should be included in the process of conceptual modelling and how a conceptual model should be

described. It is useful to consider what constitutes a conceptual model before defining what is

meant by the process of creating a conceptual model. The reason for this is that discussions have

considered the former while the process is dependent upon what information it needs to provide.

Three of the key debates in conceptual modelling noted by Robinson (2008a) are important to an

understanding of what constitutes a conceptual model. The conceptual model is a simplified

representation of the real system; independent of any software-requirements and is viewed from

both the client and modellers perspective. Robinson (2004b, pg. 65) has to some extent

addressed these issues in a definition for a conceptual model. This was later reinforced in

41

Robinson (2008a, pg. 282) with a detailed examination of recent definitions and requirements in

conceptual modelling:

'a non-software specific description of the simulation model that is to be developed, describing the objectives, inputs, outputs, content, assumptions and simplifications of the model’.

There are two considerations that are not necessarily addressed in Robinson’s (2004b; 2008a)

definition. The first consideration has previously been pointed out by Haddix (2001), that a key

contributory factor that adds to the confusion over defining a conceptual model is whether the

conceptual model is an artefact of the user or the designer. The other includes the alternative

way in which the content of a model can be described. Robinson’s definition is deliberately

general and not biased to a particular worldview or application domain. However, the debates

and challenges for conceptual modelling are hugely dependent upon different modeller’s

worldviews and application domain particularly when describing the content of the model.

In relation to the first consideration, Robinson (2008a) does consider two different types of

conceptual model:

1. domain-orientated model - provides a detailed representation of the problem domain

(actual practice)

2. design-orientated model - describes in detail the requirements of the model, which is

used to design the model code (modelling practice)

The two different types of conceptual models present a gap between the real world

understanding of the subject matter experts (SME’s) and the modeller(s) who design and build the

computer simulation model. The domain-orientated model describes the problem as it exists in

the real world. Usually this is defined from the perspective of the client and extracted by

interviewing subject matter experts who are knowledgeable about the real system being studied.

Another view is that a process reference model could be used to describe a supply chain; this idea

is one of the central themes developed in this thesis. Taking a Supply Chain Council SCOR view

this would include a description of the business processes and activities; relationships between

processes and the practices adopted in one or more process.

The content of the model (second consideration) can be linked to how the design-orientated

model is described. It is when the components of the model that represent the real world

problem are described that alternative perspectives exist. This can be seen in Pace’s (2000a, pg.

329) definition of a conceptual model:

42

‘Describes how the simulation developer understands what is to be represented by the simulation (entities, actions, tasks, process, interactions, etc.,) and how the representation will satisfy simulation requirements’.

There might be alternative perspectives of how to describe the content of the model but standard

terminology has been described for particular worldviews or even simulation approaches. For

example, Pidd (2004a, pp. 63 – 66) discusses the standard terminology used in DES. This includes

the labels for the objects that constitute a system to be simulated (e.g. entities, resources);

definition of operation in which these objects engage over time (e.g. events, activities and

processes). In an SD approach, the objects and operations concern stocks, flows, casual loops and

delays while in agents based modelling these include agents, rules and state charts (Owen et al.,

2008).

There is even less discussion in the literature on how a conceptual model is created. The first key

facet considered by Robinson (2008a) considered the need to move from problem situation,

through model requirements to a definition of what is going to be modelled and that it is an

iterative process. This is the closest Robinson gets to a definition for conceptual modelling

although in Robinson (2004b; 2008a) a framework is presented. Pace (2000a, pg. 329) does offer a

definition for conceptual modelling:

‘Collection of information that describes the simulation developer’s concept about the simulation and its pieces (e.g. assumptions, algorithms, characteristics, relationships and data)’

The definition offered by Pace (2000a) leans towards the design-orientated model perspective. It

takes a view that the problem can be extracted from the real world from the perspective of the

modeller (i.e. the modeller makes judgments about the content of the model and how

assumptions and simplifications can be incorporated into the model). In Pace’s (2000a) view this

would concern the relationships in the model, or more specifically the components in the model

and their interconnections. This has two dimensions, which are familiar and well understood

concepts in the simulation literature (e.g. Brooks and Tobias, 1999; Chwif, Barretto and Paul,

2000; Carson, 2004, Law, 2008, as previously published in 2005 and 2006):

The scope of the model: The model boundary or the breath of the real system that is to be

included in the model (e.g. Law, 2008)

The level of detail: The detail to be included for each component in the model’s scope

The model content is determined, in part, by the inputs and outputs, in that the model must be

able to accept and interpret the inputs and to provide the required outputs (Robinson, 2008a).

43

The inputs refer to the elements of the model that can be altered to effect an improvement in, or

better understanding of, the real world. In a SCM context these relate to the characteristics of

the improvements selected to improve supply chain performance. The outputs therefore are the

specific supply chain measures that can be used to evaluate the performance of the

improvements being observed.

The distinct challenge is the ‘conversion’ between the real world in which the supply problem

exists (domain-orientated view) and the way in which the modeller wishes to represent the model

content (design-orientated view). This includes understanding the problem in enough detail and

extracting information from the clients so that the model content can be derived. This is perhaps

why conceptual modelling is often regarded as an ‘art’. It is this conversion that presents the

greatest difficulty in conceptual modelling which would benefit greatly from approaches that

could help create a conceptual model. These approaches would be hugely dependent upon the

requirements for SCM applications. There is also another opportunity that is argued explicitly in

chapter six that the process of conceptual modelling could be made more efficient and focused by

utilising existing domain knowledge. This is required to formulate the real world problem from

the perspective of the client and to use standard terminology adopted in SCM practice.

2.6 Understanding of CM for SCM simulation applications

This section discusses the general understanding of simulation conceptual modelling for SCM

applications. It argues that conceptual modelling is little understood in the literature and even

when applied in practice. Particularly within the domain of SCM management there are no

guidelines that could aid the participants through the complexity of creating a simulation

conceptual model. The section contributes to demonstrating that a gap exists for a methodology

that can provide some guidelines that can be followed specifically for SCM applications. This is

developed by considering:

General issues in understanding of conceptual modelling in practice (section 2.6.1)

Application of the process of conceptual modelling in practice for SCM applications

(section 2.6.2)

2.6.1 General issues in understanding of conceptual modelling

The extent to which conceptual modelling is understood and conducted is difficult to ascertain.

Robinson (2004a; 2004b) who notes that when reviewing previous simulation related conferences

and papers that have used a simulation approach over the previous four decades they did not

provide much description of the conceptual model or how one might be created. In particular

44

there is little written justification of the design choices made when formulating the scope and

detail necessary to model a specific supply problem and examples of conceptual models. Three

reasons might be attributed to these issues:

1. Conceptual modelling is seen as more of an ‘art’ than a ‘science’ (e.g. Shannon, 1975,

1992; Kleijnen, 1995; Anderson, Richardson and Vennix, 1997; Schmeiser, 2001; Robinson,

2004b; 2006a; 2006b; Banks et al., 2005)

2. Novices devote little time to the conceptual modelling stage, while experts draw upon

prior experience build up over a period of time (Wang and Brooks, 2007a)

3. Little guidance offered in texts and research papers on how to create a simulation

conceptual model (Robinson, 2004b)

The first reason presents a difficultly in defining methods and procedures for the creation of a

conceptual model (Robinson, 2006a; 2006b). Schmeiser (2001) makes this point by comparing

model conceptualisation to the analysis of the model stage which he contends is more of a

science, therefore easier both to teach and to undertake. Conceptual modelling requires specific

skills that expert modellers have gained over a period of time. Identifying a greater

understanding and some more formal methods for conceptual modelling would have some

significant benefits (Robinson, 2006a; 2006b). For instance it could enable novices to gain these

skills quicker, averting some modelling failures. Additionally, experts will gain from having a more

formal process for guiding them through the process of conceptual modelling, relying less on

hopeful intuition and more on guided practice.

There are some studies that review the simulation practices between novices and experts (e.g.

Willemain, 1995; Powell and Willemain, 2007; Wang and Brooks 2007a). Each study found

considerable differences to the approaches to conceptual modelling and in particular the

conceptual modelling stage. Willemain (1995) found that experts would tend to develop an aspect

of the conceptual model, then evaluate it and then often revise the conceptual model based on

this evaluation. Powell and Willemain (2007) later found that novices often fall short of what they

considered good modelling practice due to over-reliance on data, taking shortcuts, insufficient use

of variables and relationships, ineffective self-regulation and over-use of brainstorming. Wang

and Brooks’ (2007a) study reinforced these points and surprisingly, contends that novices lacked

consideration of the conceptual model. On the other hand experts devoted much more time to

the step and revisited the conceptual model as knowledge improved during the project. Ward

(1989) suggested that what sets truly successful modellers apart is their effectiveness in

45

conceptual modelling. The expert modellers were able to draw upon their experiences which

increased the success of the simulation study meeting objectives and time scales.

There is little guidance offered on conceptual modelling in both simulation texts and the wider

academic literature. Robinson (2004a; 2004b) points out that conceptual modelling is probably

the least understood aspect of simulation modelling, with very little written on the subject. Wang

and Brooks (2007a) support this view by suggesting there is a lack of empirical studies or data in

the literature on how modellers develop conceptual models and on how conceptual modelling

relates to other modelling topics. Simulation texts show very little discussion on conceptual

modelling (e.g. Greasley, 2004; Pidd, 2004a; Banks et al., 2005) except in Robinson (2004b) who

devotes two specific chapters to conceptual modelling. This is also the case in the literature,

where some papers exist of successful simulation projects as a whole (e.g. Law and McCormas,

1991; Musselman, 1994; Nordgren, 1995) with some discussion of conceptual modelling.

Recently, there has been an attempt to provide some guiding principles and examples of

conceptual modelling most notably after two specific tracks dedicated to conceptual modelling at

the Operational Research Society Simulation Workshop in 2006.

2.6.2 Application of the process of conceptual modelling for SCM problems

The issues surrounding a lack of understanding of conceptual modelling in general are

compounded by the actuality that there is little evidence of the application of the process of

conceptual model for SCM applications. This does not mean that a conceptual model has not

been described prior to building the computer model. Moreover, they have not been presented

in great deal in research publications. The relevance of a greater understanding of conceptual

modelling is more prevalent due to the nature and complexity of evaluating supply chain

problems which has previously been argued (see section 2.3).

Manuj et al., (2009) discuss how to improve the rigour of discrete-event simulation in logistics and

supply chain research. Although, this is in the context of DES, they offer an eight-step process for

general use in the design and execution of rigorous simulation work building upon contributions

by Banks (1998) and Law (2008). The review demonstrated that only a few of the eight steps

were covered adequately and specifically highlighted that the conceptual modelling stage had

inadequate coverage and been neglected (i.e. not reported or not sufficiently addressed). In

particular, Manuj et al., (2009) raised the issue of the critical step of validating a conceptual

model, suggesting that there is little evidence in the logistics and supply chain literature, both in

the studies they examined in detail, and those that were excluded. It was also difficult to find

46

evidence of much detail of conceptual models presented in the literature for the other simulation

approaches (e.g. SD, MABM).

The sample of DES studies studied by Manuj et al., (2009) in SCM presented only one study which

had documentation to show the completion of the conceptual modelling step. Appelqvist and

Gubi (2005) specified that their model was compared to actual supply chain performance and

reviewed a structured walk-through with company management. However, Manuj et al., (2009)

point out the conceptual validation and walk-through was done during simulation model

validation (at a later stage of the simulation project). More recently, Onggo, Gunal and Maden,

(2008) were the only researchers to present a conceptual model of a supply chain problem

(modelling a distribution warehouse) and James and Bhasi (2008) classified models for conceptual

modelling of logistic terminals. Three other examples can be found that focus on a lean

manufacturing problem (Van der Zee, Pool and Wijngaard, 2008), views of modellers on the

conceptual modelling process (Wang and Brooks, 2008) and the complexity of simulation

problems (Heavey, 2008). It should be noted that the examples noted above have only recently

been published; little literature exists in this area prior to 2008.

2.7 Usefulness of a CM methodology for SCM applications

There is a need for structured approaches that could guide the participants in a simulation project

through the process of creating a conceptual model for SCM applications. This would require

following steps that could facilitate a good understanding of a complex supply problem so to

formulate the modelling requirements and lead to a definition of the computer model to be

developed.

A simulation conceptual modelling methodology for SCM applications would be useful in terms of:

1. Incorporating and building upon existing conceptual modelling practice, developed in the

context of evaluating supply problems (addressed in chapter four)

2. Meeting the requirements for an effective conceptual model, the characteristics of a good

methodology and address the specific needs of the SCM domain (addressed in chapter

five)

3. Incorporating key concepts that address how the participants undertaking a conceptual

modelling stage of a simulation project for SCM applications can be guided through the

process of creating a conceptual model (addressed in chapter six)

47

Existing conceptual modelling practice can be viewed in light of the specific needs for creating a

conceptual model for SCM applications. This would include understanding the approaches to

conceptual modelling in practice (discussed in section 4.1) and incorporating these into a guide.

In particular understand how the principles of conceptual modelling, methods of simplification

and a general process can be incorporated into a methodology. A methodology that is founded

upon existing conceptual modelling practice should minimise some of the general pitfalls that

could be avoided in simulation modelling (identified in section 4.2). It would also include ways

and means to communicate and represent the content of the conceptual model (identified in

section 4.3). Another important aspect that could be incorporated into a methodology is how to

validate a conceptual model (identified in section 4.4).

A methodology could be developed that meets a specification that details the requirements that

it should include. This would include the creation of an effective model that is simple for the

purpose at hand and creates a conceptual model that is both valid and credible (identified in

section 5.1). It addresses the need, of the good characteristics, of a methodology, that includes a

procedure that guides participants through the process of conceptual modelling with the

appropriate information (identified in section 5.2). Additionally it would address and capture the

specific needs of conceptual modelling for evaluating a supply problem (identified in section 5.3).

A methodology would incorporate some key concepts that are founded on existing practice and

ideas for improving and identifying ways on how to create a conceptual model for SCM

applications. These ideas are formed by bringing together some important issues in conceptual

modelling such as:

Identify how the participants undertaking the conceptual modelling stage of a

simulation project should be involved in the process of conceptual modelling (identified

in section 6.1) - In particular understanding a domain requirements specific to the client’s

perspective of the supply problem and converting this into a design-orientated model that

expresses the perspective of the modeller.

Identify a general process for creating the conceptual model (identified in section 6.2) -

The key concepts identified for SCM applications can be incorporated into this process.

Identify the domain needs for creating a conceptual model (identified in section 6.3) –

Consider how the knowledge of the SCM domain can improve the process of conceptual

modelling and the guidelines that should be followed to make them more detailed,

focused and efficient.

48

2.8 Benefits of developing a conceptual modelling methodology for

SCM applications

The development of a conceptual modelling methodology for SCM applications will yield

significant benefits to both practitioners and researchers who use a simulation approach to

evaluate supply problems. The primary benefit of completing the conceptual modelling stage

successfully is that it will improve the quality of the output from a simulation study (Manuj et al.,

2009). This should lead to a model that is simple for the purpose at hand; both valid and credible.

There are a host of secondary benefits that can be identified which are significant in their own

right. These can mainly be considered in light of Robinson’s (2006a; 2006b) discussion of the key

issues that should be addressed by the research community to further an understanding of

conceptual modelling and impact upon the practice of simulation modelling more generally. He

suggests that research that addresses these issues will have substantial benefits to both novice

and expert modellers:

help novice modellers obtain modelling skills more rapidly, thus averting some modelling

failures

experts will gain from having a more formal process guiding their modelling, relying less

on hopeful intuition and more on guided practice

Each of the research issues suggested by Robinson (2006a; 2006b) can be considered in light of

the purpose of this research project and what this research delivers:

1. Developing consensus over the definition of a conceptual model/conceptual modelling

– Definition is offered for a conceptual model and the process of conceptual modelling for

SCM applications

2. Identifying the requirements for a conceptual model – Identified specifically in the

context of SCM applications

3. Development of methods for designing conceptual models including modelling

principles, methods of simplification and modelling frameworks – Incorporated into the

key concepts for conceptual modelling and aligned to a general process

4. Moving towards standard methods for representing and communicating a conceptual

model – Templates are suggested for presenting information, using this information to

undertake the necessary analysis and for documenting the conceptual model

5. Developing procedures for validation of a conceptual model – Incorporated into the

process and at the final phase of the methodology

6. Investigating effective means for teaching the art of conceptual modelling – Provides a

set of guidelines that could be used by both expert and novice users. More so, educate

49

novice modellers so that they can become more effective practitioners (Willemain and

Powell, 2007)

2.9 Chapter summary

This chapter has discussed the research issues in conceptual modelling for SCM applications. It

demonstrates that a gap exists for a methodology that utilises domain-knowledge combined with

a procedure that can be followed to create a simulation conceptual model for SCM applications.

It has been argued that the evaluation of supply problems is of critical importance to an

organisation seeking to identify ways to improve performance. The difficulty involved in

identifying and evaluating improvements is that a supply problem is inherently complex.

Simulation is one such approach that can address the complexity of a supply problem and the

extent of its use in both research and practice is great.

One particular issue in the simulation literature is the need to develop further an understanding

of conceptual modelling. This is deemed an important and critical stage of a simulation project.

Little is written on conceptual modelling in general and particularly in the domain of SCM. An

area that is underdeveloped and requires attention for research is that there is a distinct lack of

guidelines that could be followed to create an effective conceptual model. A methodology that

can aid in the creation of a simulation conceptual model for SCM applications is one way that

could help fill this gap. It will be useful as it could guide a modeller through a complex supply

problem to identify how it could be modelled. Additionally it would yield significant benefits to

both research and practice (particularly expert and novice modellers) by addressing to a large

extent the research issues raised by Robinson (2006a; 2006b) and aid in the improvement of the

output from a simulation study.

The following chapter identifies, and justifies, a research methodological programme to realise

each of the research objectives, and questions, so that an SCM2 can be developed and tested.

50

Chapter 3 Research programme for the development and

preliminary validation of the SCM2

This chapter describes and justifies the research programme and methods used for the

development and preliminary validation of the SCM2. This is normally called the ‘research

methodology’ but the term ‘research programme’ is used to avoid confusion between the

methodology to be developed and tested and the way in which the research has been conducted.

The aim is to design a methodological approach, which addresses the research objectives and

underlying research questions in the most suitable way. The chapter is broken into the following

seven sections before summarising:

Justification of methodological approach (section 3.1) – justified by considering the

research methodological issues and debates regarding the development of business

methodologies. It also identifies the stages necessary to address these issues in the

context of the research problem.

Research programme and methods (section 3.2) – The research methods adopted in

each stage of the research programme are described with discussion on the choice and

rationale considered

Development and validation case applications (section 3.3) – Discusses issues

surrounding the involvement of the researcher, consistency of the process and choices of

existing cases to be studied

Limitations of the research approach (section 3.4) – Identifies that further applications

are required to be tested against the test criteria and the need to test the wider

applicability of the methodology

Validity and reliability of the research (section 3.5) – Some points are raised to ensure

the results of the study are repeatable and the integrity of the conclusions

Ethical considerations and issues (section 3.6) – To ensure the work meets with ethical

standards for research

3.1 Justification of methodological approach

This section reviews and justifies the methodological approach adopted to address the research

aims of this thesis. The end result is a five stage research methodological programme to develop

the SCM2. This is identified and justified after considering issues in the following areas:

Identification of existing approaches to develop a business methodology (section 3.1.1)

– It is argued that no examples can be identified for the development of methodologies

for conceptual modelling

51

Identification of key methodological issues that have been discussed for the

development of the SCM2 (section 3.1.2) – A number of important considerations are

identified to establish a strong conceptual base, the need for empirical and theory testing

and to ensure the results are relevant to the practicing manager

Examination of existing methodological approaches in the field that are related to the

development of the SCM2 (section 3.1.3) – Identification from the general research

methodology literature some of the key issues to address the issues for developing the

business methodology

Justification of five stage approach to design a SCM2 (section 3.1.4) - The overall

approach includes the need to review existing conceptual modelling practice, form the

specification and outline design, refinement of the design and preliminary validation is

described and justified.

3.1.1 Methodological approaches for the development of methodologies

There are no guidelines available on research approaches for the development of a conceptual

modelling methodology because it is a novel area for research. Previous discussions of

approaches that would be useful in the conceptual modelling stage have, on the whole, been

developed from experience with very little testing. The most detailed and comprehensive

guidance for conceptual modelling has been presented in Robinson’s (2004b) book entitled

‘Simulation: The practice of model development and Use’. The guidelines are based upon the

author’s experience of nearly 20 years, with developing and using simulation models of

operations systems, mainly manufacturing and service systems (Robinson, 2008b). The

framework has not undergone any claimed testing, although recently in Robinson (2008b) one

example (i.e. Ford Motor Company) is used to illustrate the framework but this has not been

presented as a formal validation. All that is claimed is that the framework would be a useful

approach to conceptual modelling in general.

The research project aims to create scientific knowledge by developing a methodology that

combines domain knowledge with a procedure to be followed. Therefore, emphasis is placed

upon theory building rather than theory testing. The scientific theory building process has been

discussed in the OM literature (e.g. Meredith, 1993, Handfield and Melnyk, 1998, Voss et al.,

2002) but not in the context of developing methodologies. Voss et al., (2002) points out the main

aim of theory building research is to: ‘Identify/describe key variables, identify linkages between

variables and identify why these relationships exist’. This is achieved by following the normal cycle

of research that moves from description to explanation to testing with continuing iteration

through the cycle (Meredith, 1993). This thesis does not attempt to test the methodology

52

developed. However, confidence in the methodology is improved through a process of

refinement and preliminary validation. Future work is suggested to iterate between explanation

and testing of the methodology with actual users, primary data, and researcher observation until

eventual theory can be said to have been developed.

3.1.2 Key methodological issues in the area of developing a methodology

There have been a host of different methodologies developed in the OM and SCM literature in

general but little has been written on how one can be developed. One notable exception is Platts

(1993) who discussed three shortcomings of existing contributions when considering research

methodological issues for developing a process framework for formulating and implementing a

manufacturing strategy. These three issues are also important considerations for developing a

SCM2. These include:

1. Poor conceptual base

2. Low levels of empirical and theory testing

3. Relevance of the results to the practicing manager

The first issue has received attention in the SCM literature in general, noting the need towards

more theoretical development and discussion required (Croom et al., 2000; Ho, Au and Newton,

2002; Harland et al, 2006). Baines (1994) discussed the need for a strong conceptual base as it

provides a foundation on which further work can be built and future contributions

compared. Baines also cites De Bono (1992) in support, who suggested that ignoring existing

practice may have an influence on the originality of the work but it is of high risk if the work is to

proceed in a logical manner. A conceptual base can be established by identifying and analysing

existing practice and forming a set of requirements that the SCM2 must meet at the design stage.

The second issue has received attention in the SCM literature from Croom et al., (2002, pg. 75)

who adds that the ‘inductive-deductive dichotomy is best addressed through constant reflection

of empirical against theoretical studies’. This can be remedied by having a strong theoretical base

and applying the methodology to empirical cases. Testing can be regarded as a separate issue,

once the methodology has been designed, developed and refined. It was previously noted that

Robinson’s (2004) process framework has undergone no formal testing. Although as Hill (1987)

points out, testing is important and improves the rigour of the research. Iterative reflection

between a strong conceptual base (from theory) and empirical data would increase the validity of

the findings but the reliability is dependent mainly upon the number of applications.

53

The third issue (usefulness to the practicing manager) is also relevant for the context of the

methodology being developed. ‘Usefulness’ in this context is a methodology that aids a modeller

in the creation of a conceptual model as part of a simulation project and for the benefit of the

client. Platts (1993) suggests that there are two research approaches that ensure the scientific

rigour of work (internal validity), and relevance to organisations (external validity), these are of

particular interest to the development of new theory. These include case study research (e.g.

Voss et al., 2002) and action research (Couglan and Coghlan, 2002).

3.1.3 General methodological issues for developing the SCM2

This section considers the general research methodological issues for developing the

methodology. Beech (2005) provides a useful map to discuss the various alternative

considerations when discussing the research design. This map includes:

Ontology (section 3.1.3.1) – concern the nature of reality (Saunders et al., 2007)

Epistemology (section 3.1.3.2) – general set of assumptions about the best ways of inquiring

into the nature of the world (Easterby-Smith et al., 2004, pg. 31)

Methodology (section 3.1.3.3) – combination of techniques used to enquire into a specific

situation (Easterby-Smith et al., 2004, pg. 31)

Techniques (section 3.1.3.4) – individual techniques for data collection, analysis etc.,

(Easterby-Smith et al., 2004, pg. 31).

3.1.3.1 Ontology

There are two main ontological positions often used to describe differences that may influence a

researcher’s assumption about how social entities operate within the world. Bryman and Bell

(2007, pg. 22 – 23) define these as:

Objectivism (objective) – implies that social phenomena confront us as external facts that

are beyond our reach or influence

Constructionism (or subjective) – asserts that social phenomena and their meanings are

continually being accomplished by social actors.

The social phenomena being studied in this thesis is how a simulation model can be created for

SCM applications. The research questions seek to identify the requirements for creating a

conceptual model for SCM applications and developing a methodology that meets these

requirements. It can be argued that the social phenomena under study should be viewed from a

subjective ontological position. The rationale for this is that conceptual models are produced

through social interaction and involve a state of revision. The new knowledge created is formed

54

via participants in the simulation study taking part in a series of procedures that extract and refine

the information required. The conceptual model is therefore not external from the social actors;

it is shaped by those actors.

The implication of considering the ontological considerations is that the research method should

seek to identify how a conceptual model is created for a given supply problem and by actors

undertaking the study. Both Baines (1995) and Platt’s (1993) can be said to have used subjective

positions when developing their frameworks. The frameworks were developed by applying them

to different types of problems and revising the procedure based upon new knowledge created.

The involvement of the researcher in the process of studying the phenomena was noted as a key

issue when developing a framework or methodology (this is revisited and addressed in section

3.3.1).

3.1.3.2 Epistemology

There is significant debate in both the SCM and OM literature between the different research

epistemological positions that could be adopted to realise the aims of this research project.

Beech (2005) suggests four epistemological positions, two linked to an objective ontology

(positivist and critical realist) and a further two linked to a subjective ontology (interpretivist and

action research). Generally, two of these approaches have been dominant in the social sciences:

positivist and interpretative paradigms (Hussey and Hussey, 1997) which are commonly, but not

exclusively, associated with quantitative (in the positivist paradigm) and qualitative (in the

interpretative paradigm) research. These can be defined as:

Positivist - research entails the collection of data upon which to base generalisable

propositions that can be tested (Pugh, 1983). With this approach the researcher is likely

to use existing theory to develop hypothesises and test them so to further develop theory

(Saunders et al., 2007).

Critical realist - takes a middle view, a compromise which can combine the strengths and

avoid the limitations of positivist and interpretivist paradigms (Ates, 2008).

Interpretivist - research requires the researcher to grasp the subjective meaning of social

action (Bryman and Bell, 2007). It recognises that reality is not objective, but rather a

social construction, created within the minds of those individuals interacting (Lee and

Lings, 2009).

Action research - involves taking action and creating knowledge, or theory, about that

action (Coughlan and Coghlan, 2002).

55

Both positivist and critical realist epistemological positions would not be suitable for this type of

research as they are associated with an objective ontology. There are a number of reasons why a

positivist led study would be inappropriate. The key reason is that there is little existing theory on

methods for creating conceptual models, particularly in SCM, and no methodologies exist. It

would not allow rich insights to understand how a conceptual model can be created. This cannot

simply be reduced to a series of law-like generalisations and the aim of the research is to produce

a methodology that can aid a user. Guba and Lincoln (1994) provide some other criticisms of a

positivist approach that can be considered in light of developing a methodology. For instance, a

positivist approach excludes meaning and purpose particularly understanding of how a human

may create a conceptual model and excludes the discovery dimension in inquiry as the hypothesis

is determined in advance leading to less creative input.

Both interpretivist and action research epistemological positions fall into a subjective ontology.

An interpretivist approach would allow a rich and ideographic description of experiences within

their contexts (Lee and Lings, 2009). This is also true of an action research approach, however;

the researcher would be a participant in the creation of the conceptual model and make

observations to learn how it might be improved. An interpretivist researcher would not

necessarily seek to influence the creation of the conceptual model. They would look at

organisations in depth and generally appoint to extensive conversations, observations and

secondary data analysis such as company documents and reports in order to overcome

generalisability critiques (Easterby-Smith et al., 2004, pg. 40). There are some issues around

action research being uncertain and sometimes an unstable activity (Coughlan and Coghlan,

2002). The approach would require access to the participants undertaking a simulation conceptual

modelling project for SCM applications over a considerable length of time. An interpretivist

approach is preferred at this stage of researching into the creation of conceptual models. The

main reason being that data can be used to develop theory within different contexts, prior to

gaining access and observing participants or taking part in using the actual methodology.

3.1.3.3 Methodology

Methodology concerns the combination of techniques used to enquire into a specific situation

(Easterby-Smith et al., 2004). Beech (2005) suggests three alternative approaches that could be

taken:

Hypothetico-deductive – an approach that should formulate theory or an hypothesis to

explain some results and use these to derive further predictions or statements that can be

verified or falsified through testing

56

Inductive – an approach to the relationship between theory and research in which the

former is generated out of the latter (Bryman and Bell, 2007)

Co-operative inquiry – a way of working with other people who have similar concerns and

interests to the researcher. This is used to make sense of the people’s world, develop new

and creative ways of looking at things and learn how to act to change things (Heron and

Reason, 2001).

The hypothetico-deductive methodology can be discounted as it is generally applied within the

positivist paradigm. Likewise, co-operative inquiry is seen as an action type of research with high

levels of involvement by the researcher (Ates, 2008) which has already been discussed. An

inductive methodology is generally associated with an interpretivist epistemology.

At the core of the research is the need to follow an inductive construction of theory from

observations as part of the theory building process. This includes the identification of a set of key

concepts that can be incorporated into a design for a SCM2 and additionally, developing a

procedure for addressing how a conceptual model can be created. This corresponds to drawing

empirical generalisations by transferring ideas into understanding or laws. This is followed by

creating theories from empirical observations in what Weick (1989) calls a process of ‘disciplined

imagination’ (i.e. series of thought trails establishing conditions and imaginary outcomes in

hypothetical situations). The theory in this instance is built by taking each of the empirical

generalisations to develop and refine a procedure that utilises domain specific knowledge. This

requires addressing ‘how’ the concepts can be incorporated into the methodology and ‘why’ they

aid in the process of creating a conceptual model.

3.1.3.4 Methods and techniques

The Beech (2005) research design map can be used to provide some indication of the alternative

methods and techniques that could be used for this research study, informed by the choices made

previously. In this case the work falls into the subjective (ontology), interpretivist (epistemology)

and inductive (methodology) categories of techniques. Following the Beech (2005) map, three

categories of techniques can be considered:

Case study – involves ‘an empirical inquiry that investigates a contemporary phenomenon

within its real-life context, especially when the boundaries between the phenomenon and

context are not clearly evident’ (Yin, 2003, pp. 13).

Observations/participation – includes direct observation, participant observation and

action research.

57

Survey research – involves the collection of information from individuals (through mailed

questionnaires, telephone calls, personal interview, etc.) about themselves or about the

social units to which they belong (Rossi et al., 1983).

3.1.3.4.1 Case-study technique

A case study method is particularly beneficial when investigating new research areas or subjects

where existing theory is inadequate (Eisenhardt, 1989). Case-studies are often seen as inherently

flexible in that the research scope can expand to encompass new issues that may arise as the

investigation progresses (Beach et al., 2001). They are particularly important for addressing ‘how’

and ‘why’ questions (Yin, 2003), taking into account contextual factors but at the same time

limiting the extent of the analysis (Eisenhardt, 1989; Voss et al., 2002; Seuring, 2008). This is

important as there is a considerable lack of understanding of conceptual modelling for supply

chain problems in its real life context. A new approach is being developed and behaviours are

unknown. These problems can be studied with a good degree of intensity (Benhasat, Goldstein

and Mead 1987) and detail so that the SCM2 can be refined and validated to show that it works

before implementation in practice.

3.1.3.4.2 Observation and participation techniques

Platts (1993) cites Gold (1959) who suggests three different roles that a researcher could take

when developing a framework or methodology:

Direct observation - would involve the researcher being detached from the process and

witnessing how participants are undertaking the process

Participant observation - involves the researcher taking part in the process to observe but

not take part in the way in which the participants are undertaking the process

Action research - goes one step further by enabling the researcher to take part in the

process and seek to influence the way in which the activities are conducted.

Platts’ (1993) argued in the context of developing a framework that the research should set out to

actively apply the process that had been developed, both to test it and refine it in practical

situations. At this earlier stage of development it would be difficult to observe or participate in a

project as no methodology or even guidelines currently exist. It is first necessary to design an

outline of the methodology and apply it so that the detail inherent in the procedure can be

refined. Platts (1993) argued that action research would be a suitable method but instead of the

researcher being the ‘consultant’ they should act as a ‘facilitator’. Benton (2009) suggested that

acting as a ‘consultant’ may invalidate the results from the refinement and validation stages. This

58

is because the methodology is being altered and modified during the application so that it meets

the specification of requirements in the context of the supply problem.

There are a number of approaches that could be used by the researcher to make observations.

This includes using the literature to establish a strong conceptual base on existing practice in

simulation conceptual modeling within the context of SCM applications. In addition to this,

grounded theory has been noted as an approach to conducting qualitative theory building

research in management (Suddaby, 2006). Although little evidence exists of its explicit use in OM

research (Binder and Edwards, 2010).

Grounded theory is appropriate when research and theory are at their early, formative stage and

not enough is known on the phenomenon to state hypotheses prior to investigation (Auerbach

and Silverstein, 2003). The approach offers a ‘compromise between extreme empiricism and

complete relativism’ by articulating a middle ground in which systematic data collection is used to

develop theories that address the interpretive realities of actors in social settings (Suddaby, 2006,

p. 634). Also, similar to a case-study method the major research interest lies in the identification

and categorisation of elements and the exploration of their connections within social settings.

Glaser and Strauss (1967, p. 6) suggests that these concepts come from the data, ‘but are

systematically worked out in relation to the data during the course of the research’. Binder and

Edwards (2010) highlight that a great variety of sources and evidence can be used (e.g.

documents, archival records, interviews, field observations) to categorise a holistic and

meaningful set of characteristics of reality. This is achieved through a process of iteration

(analytical induction), so data is collected and analysis is preceded in tandem, repeatingly

referring back to each other (Bryman and Bell, 2007). This is conducted until theoretical

saturation is achieved which is when newly analysed data do not warrant any further changes to

the concepts (Binder and Edwards, 2010).

59

3.1.3.4.3 Survey research

Survey research is a way to collect information from one or more people about the phenomena

being studied. The method is generally associated with a positivist paradigm in order to achieve

systematic observation, interviewing and questioning through predetermined research questions

with the intention of providing standardization and consistency (Fink, 2005; Moser and Kalton,

1971). Yin (2003) also notes that the method is appropriate for answering ‘what’ type of research

questions. A survey method would not be appropriate for addressing ‘how’ a conceptual model

could be created. Although, two types of survey could be relevant:

Exploratory survey - could be used to gain preliminary insight to establish existing

practice in conceptual modeling for SCM applications. This type of survey is generally

used when there is no model and concepts of interest need to be better understood and

measured (Forza, 2002). Forza (2002) notes that in the preliminary stages exploratory

survey research can help to determine the concepts to be measured in relation to the

phenomenon of interest, how best to measure them and how to discover new facets of

the phenomenon under study.

Descriptive survey – could be used to understand the relevance of the methodology from

the perspectives of potential users. The aim is not theory development but it can provide

useful hints for further theory building and theory refinement (Dubin, 1978; Malhotra and

Grover, 1998; Wacker, 1998; Forza, 2002).

The exploratory survey is not necessary as the literature can be used to provide the conceptual

base on existing practice in conceptual modeling and the outline design for the methodology. The

main aim of the research is to identify ‘how’ the concepts identified in the design can be

incorporated into a procedure that utilises domain-knowledge. This requires the design to be

applied in a number of different contexts. The descriptive survey has been noted previously as an

important part of a research design for a methodology or framework but usually is noted as

further work after the initial development and testing stages.

3.1.3.4 Discussion and justification of techniques

Case studies, using the literature and grounded theory would each, or a combination, would

present a useful approach for this research project. As suggested by Platts (1993) there is a need

to apply the methodology to a small number of case applications so that the methodology can be

refined and validated. Grounded theory can incorporate a set of cases and provides a process

that can be followed to analyse data in an iterative way. A potential problem of conducting

original case studies is that it takes considerable time and financial expenses making grounded

theory development relatively inefficient (McCutheon and Meredith, 1993). One approach that

60

can address these issues includes a novel inductive approach termed ‘iterative triangulation’

which has been used successfully in past research (e.g. Mintzberg et al., 1976 and Kelley, 1986).

Iterative triangulation offers a rigorous process and explicit techniques for comparing diverse case

settings and incorporating varied research perspectives to aid in the development of creative,

useful and valid OM theory (Lewis, 1998). The method searches for patterns among cases,

iterates between case evidence, reviewed literature and intuition to extend and link conjectures

into a cohesive theory (Lewis, 1998). Data is analysed using existing cases as an efficient and

effective means for theory development. Lewis (1998, pg. 457) argues that ‘analysing existing

cases taps an often abundant source of field-based information, while conserving valuable

resources that would have been needed to conduct multiple, original case studies’.

Larsson (1993) suggests the cases are selected to provide imaginative means to link purposefully

varied and often seemingly contradictory case situations. Additionally, consider different case

authors perspectives to potentially reduce researcher bias. This is of particular value as it would

be difficult to access primary data from companies to create an original case-study for conceptual

modelling of SCM applications. The rationale for this includes there is a lack of methods and

understanding of how a conceptual model should be created. The emphasis in this research is to

identify how a procedure can be followed using domain-knowledge, through a process of being

guided by existing practice and intuition.

The methodological process of iterative triangulation includes four phases (shown in table 3.1)

following many prescriptions for developing theory using ‘disciplined imagination’ described by

Weick (1989). Iterative triangulation draws upon many similarities of a grounded theory

approach and addresses some of the limitations identified when developing a framework or

methodology. These limitations are addressed by initiating research preparation with establishing

a strong conceptual base from the literature; applying cases to develop and refine the

methodology and concluding the theory development process by evaluating the theoretical

contributions of theory prior to theory testing.

61

Table 3.13 Similarities between an iterative triangulation and grounded theory method

Iterative triangulation (Lewis, 1997)

Similarities with grounded theory process (Bryman and Bell, 2007)

Phase I Groundwork: consists of ground laying steps that define methodological and theoretical parameters. Clarifying research questions, constructs of interest, and case search strategies and selection criteria.

The process begins with setting research questions, theoretical sampling and collecting relevant data.

Phase II Induction: consists of several techniques to analyse case data, to track down patterns and consistencies and to shape initial conjectures.

The data is coded to generate concepts. There is movement between earlier steps (iteration), new data added if required and constant comparison of indicators and concepts to generate categories.

Phase III Iteration: describes iterative means of refining the emerging theory by creatively generalising beyond the data.

The categories are saturated during the coding process and relationship between categories is explored so that connections between categories emerge.

Phase IV Conclusion: concludes the theory development process by evaluating the theory and suggesting future research possibilities. This phase serves to assess theoretical contributions and to begin bridging theory development with theory testing.

Further data may be collected to test emerging hypotheses which leads to the specification of substantive theory.

In relation to incorporating principles of grounded theory these are also shown in table 3.1. A key

difference is that data is analysed using existing case applications to identify a set of propositions

that are unproven (conjectures) and thus shape how the procedure is to be formed. Weick (1989)

suggests that selecting conjectures becomes more of a matter of judgment determined by the

researcher by conducting mental experiments. The experiences and assumptions made are

reviewed with the literature and case data to evaluate the conjectures made, spurring creativity

(Lewis, 1998). The majority of the tools to collect data, code and to reach closure in the iterative

triangulation process are taken from a grounded theory method (e.g. theoretical sampling,

coding, theoretical saturation).

3.1.4 Justification of five stage approach The design of the research programme needs to address the issues discussed in the previous four

sections. No guidelines were found for designing a simulation conceptual modelling methodology

for SCM applications although some issues were raised for conducting research when designing a

framework or methodology. Additionally, it was found that work of this nature is interpretative

and requires the methodology to be applied. This discussion draws on each of these sections and

considers them in light of some recent examples of frameworks or methodologies developed in

the literature (e.g. Platts, 1993; Baines, 1994; Lee Gan Kai, 2007; Julka, 2008; Benton, 2009) and

the iterative triangulation process. The aim is to identify the stages that need to be included in

the research programme.

62

Platts (1993) proposed a three stage approach for researching manufacturing strategy, which

provides a useful starting point for considering the research design for this project. The degree to

which each of the stages is conducted in the literature varies but some common considerations

can be identified that meet the issues previously discussed. These stages include:

1. Creation of the process based upon existing knowledge – the SCM2 must be grounded in

existing theory by identifying a strong conceptual base (corresponds to phase I:

groundwork of the iterative triangulation process)

2. Testing (this thesis only claims an initial validation) and refinement through application

in a small number of companies – The design of the SCM2 would need to be refined and

validated by applying the methodology in a small number of supply chain applications

(corresponds to phase II: induction, III: iteration and IV: conclusion of the iterative

triangulation process)

3. Investigate the wider applicability of the process by survey – Once the methodology has

been initially validated in a small number of supply chain applications, its wider

applicability should be sought (not included in the iterative triangulation process)

There is consensus in the literature that a methodology needs to be developed based upon

existing practice and refined through application (e.g. Platts, 1990; Baines, 1994; Gan Kai, L.W.,

2007; Julka, 2008 and Benton, 2009). This addresses the requirement noted previously that a

methodology needs to be built from a strong conceptual base and the ‘groundwork’ initial stage

of the iterative triangulation methodological process. Firstly, existing practice would need to be

identified and critiqued and from this base a specification detailing the requirements can be

formed. Secondly, a design for the methodology is outlined building upon existing practice and

the requirements. It must be noted here that the term ‘outline’ is usually referred to as ‘concept’

in design stages but due to the nature of the methodology being developed ‘outline’ is adopted

for clarity. In order to cover the development aspects of the design the following three stages are

necessary:

1. Review existing simulation conceptual modelling practice in the context of SCM

applications - to establish the need for a methodology

2. Form a specification of the requirements for simulation conceptual modelling in the

context of SCM applications – the requirements that the design must meet

3. Develop an outline design - includes the key concepts that need to be implemented into

the methodology to meet the required specification.

The testing and refinement stage noted by Platts (1993) is open for debate and has been

approached in different ways. A distinction needs to be made into whether refinement is part of

63

the development of the methodology, testing, or both. In the context of the iterative

triangulation process this corresponds to the induction and iteration phases. The aim in this

research is to follow the normal cycle of research as described by Meredith (1993) by continuingly

iterating between descriptions to explanation but does not claim that the SCM2 has been

rigorously tested. Meredith (1993, pg. 3) notes that the result is to validate and add confidence to

previous findings or else invalidate them and force researchers to develop more valid or more

complete theories. In respect to refining the methodology it is evident that the majority of

contributions seek to refine an initial design formed from existing theory (e.g. Lee Gan Kai, 2007;

Chandraprakaikul, 2008) but in some contributions a separate validation or testing stage is less

evident, or non-existent (e.g. Apaiah, 2006; Wong and Johansen, 2007; Lima, 2008; Symeonidis et

al., 2008).

Testing has been identified as an important requirement to improve the rigour of the study. In

the contributions that present a testing stage they, on the whole, are described as a ‘preliminary’

validation, noting specifically the context in which they have been applied (e.g. Chandraprakaikul,

2008 and Benton, 2009) to demonstrate that a process or framework initially works. This

corresponds to the final phase of the iterative triangulation process when the methodology is

evaluated and future research directions described (e.g. future testing requirements). This is

necessary as the applicability of the methodology can only be claimed within the boundaries of

the applications (e.g. industry, complexity and detail of supply chain, geography). In order to split

the refinement from the preliminary validation the following two stages can be identified for this

project:

4. Detail and refinement of the outline design - so that it meets the specification previously

formed

5. Preliminary validation - illustrate the methodology against the validation criteria

The testing of the wider applicability is usually considered once the initial validation has been

completed successfully. It was difficult to identify studies that attempt all three stages identified

by Platts (1993). For instance, Yee and Tan (2004) and later in Yee and Platts (2006) developed a

framework, and tool for supply network strategy operation, based upon organisations within a

single supply chain case. A closing comment is made in Yee and Platts (2006, pg. 245) that

‘additional work is required to address the issue of the framework validation and tool application

in wider industries and sectors’ (outlined as an intention for further work). Similarly this is also

the case in Platts and Canez (2002) development of a process to aid in make vs. buy decisions

using one case-study. These examples demonstrate that initial testing is required in a small

64

number of applications and further work is needed to be able to generalise the findings. It is also

important to be clear on any deficiencies or limitations that need to be addressed at a later stage

to identify the need for testing the wider applicability. This point is considered when discussing

the outcome of the preliminary validation and made explicit in the concluding chapter.

3.2 Research programme and methods

The research programme describes the sequence of stages that has been conducted to realise the

research aim and objectives. Explicit in the aim of this research is to develop and preliminarily

validate a methodology that can support a user in the creation of a conceptual model for a given

supply chain problem. The previous section identified the research stages required to realise this

aim. Section 3.2.1 will provide an overview of the research programme and methods, and align

these to each of the research objectives and questions. The subsequent sections will describe in

more detail the rationale and approach adopted for each stage.

3.2.1 Overview of research programme and methods

The research programme is structured to firstly develop the methodology followed by refinement

and validation. This is broken down into a series of five stages that address each of the research

objectives and questions. The remainder of this thesis is structured to implement each of these

stages as summarised in figure 3.1.

Review of existing conceptual modelling practice

Stage I – chapter 4

Establish the need for a feasible SCM2

Met

hodo

logy

Dev

elop

men

t

Form the specification for the SCM2

Outline design for the SCM2

Establish the required specification for the SCM2

Stage II – chapter 5

Stage III – chapter 6

Detailed and refined design of the SCM2

Preliminary validation of the SCM2

Stage IV – chapter 7

Stage V – chapter 8

Refin

emen

t an

d pr

elim

inar

y va

lidat

ion

Outline design for SCM2

Detailed and refined design for SCM2 that meets the specification

A feasible SCM2

Figure 3.1 Overview of research programme

The specification of the requirements for creating simulation conceptual models for SCM

applications (objective one) is addressed by stages I and II of this research. Stage I (implemented

in chapter four) answers the first research question that discusses how simulation conceptual

models are created in the context of supply chain applications. Following on from this stage II

65

(implemented in chapter five) answers the second research question by detailing a specification

of a simulation conceptual modelling methodology for evaluating supply chain problems. This

ensures that the methodology is developed on a strong conceptual base which is grounded in

existing theory. The specification is used to demonstrate that the detailed and refined design

meets each of the requirements identified.

The methodology is detailed and refined so that it meets the specification of requirements

(objective two) in stages III and IV in the research programme. Stage III (implemented in chapter

six) constructs an outline (concept) design of the SCM2 that includes the identification of key

concepts and a process for conceptual modelling in the context of evaluating supply chain

management problems. This is formed by building upon existing practice and in line with the

requirements specified in stages I and II. The outline design is detailed and refined by applying it

to two representative and typical supply chain problems, addressing research question two in

chapter seven. This includes identifying how each key concept was implemented, principles and

observations identified in the refinement, and choices made and incorporated into the SCM2.

The final objective is realised by providing a preliminary validation of the initial feasibility and

utility of the SCM2 in stage V of the research programme. The aim of stage V (implemented in

chapter eight) is to show that the methodology can be followed (feasibility) and aid a user (utility)

to create a simulation conceptual model for SCM applications (research question four). The

methodology is applied to a different supply chain problem to illustrate that the steps can be

followed. The validation also draws a comparison between the actual practices to be represented

in the model with the model components included in a successfully implemented computer

model.

3.2.2 Stage I: Review of existing conceptual modelling practice

Stage I of the research programme reviews and provides a critique of existing conceptual

modelling practice. The aim is to establish whether there is a need for a methodology that could

aid a user in the creation of a simulation conceptual model for SCM applications. The key finding

discussed in the chapter is that no methodology exists for conceptual modelling and that there is

a distinct lack of guidelines available in the literature, in particular for SCM applications. The

chapter addresses the following research question:

How are simulation conceptual models created in the context of supply chain applications?

66

A critical literature review addressed this research question so that the development work was

founded on a strong theoretical basis. The review focuses upon simulation conceptual modelling

with a particular focus on SCM applications. The chapter establishes what approaches currently

exist to create conceptual models. Three methods are suggested in the literature: methods of

simplification, guiding principles, and a general framework. It was found that there lacks a clear

body of literature to provide guidelines or methods on conceptual modelling (except in Robinson,

2004b simulation text). This required the review to consider the wider literature on how

simulation projects are conducted so that the approaches that were useful at the conceptual

modelling stage could be distinguished. It was observed that the body of literature on conceptual

modelling was almost absent until Robinson (2006b) presented a paper ‘Issues in conceptual

modelling for simulation: setting a research agenda’. This subsequently led to a number of

sessions held at a workshop in 2008 on the issue of conceptual modelling (UK OR Society

Simulation Workshop, 2008). Conceptual modelling research can be said to be very much in an

embryonic stage but research on the general ‘how’ to conduct a general simulation project and

the application of simulation for SCM applications is extensive.

Due to the lack of approaches found the next focus of the review was to discuss general problems

encountered in simulation modelling. This identified that many problems are encountered in

simulation projects that could benefit from an increased understanding of conceptual modelling

and approaches that could be used. The last two sections of the review focused upon the two

important aspects of conceptual modelling that would need to be considered in a methodology.

The first discusses a mechanism for communicating the conceptual model and how its content

can be represented. The second is on the topic of ‘conceptual model validation’, which has been

suggested as an important area for study in its own right in order to improve the rigour of

simulation studies (Manuj, et al., 2009). The first had been covered in detail in Robinson (2004)

however; there is a significant lack of discussion on the topic of ‘conceptual model validation’,

particularly on the applicability of validation methods at the conceptual modelling stage of a

simulation project. To remedy this issue the general simulation validation approaches were

reviewed in order to distinguish approaches that are applicable at the conceptual modelling stage.

Each of these discussions were useful to understand what approaches could be included in a

methodology, the problems it would need to address, how it could provide a mechanism for

communicating the content and how the conceptual model could be validated.

67

3.2.3 Stage II: Forming the specification for SCM2

Stage II of the research programme identifies the requirements that the methodology would need

to address in the design stage. This builds upon the review of existing practice but concentrates

more on what the methodology has to deliver. The chapter addresses the following research

question:

What is the specification of a simulation conceptual modelling methodology for evaluating supply chain problems?

The purpose of the methodology is to create an effective conceptual model by following the

specific guidelines that address the needs for evaluating supply chain problems. Therefore the

literature examines three areas to identify a set of requirements that the methodology needs to

meet. These include:

1. Requirements for an effective conceptual model – Robinson (2004) has previously

discussed the criteria from which the success of a conceptual model is to be judged. The

implications of the discussion show that the methodology will need to build simple

models, which are both valid and credible.

2. A requirement for a ‘good’ methodology – A methodology has distinct qualities that

differentiate it from a framework, guiding principle, or method of simplifications. Platts

(1994) and Platts et al., (1996) identified the characteristics of a procedure, points of

entry and project management. The implications of these characteristics are discussed in

order to identify what the procedure should deliver, how the methodology should be

entered and iteration within the process, and justifies that project management is outside

of the scope of the methodology.

3. Requirements for conceptual modelling of supply chain problems – Discusses the

requirements for evaluating supply chain problems in the context of simulation

conceptual modelling. It specifically identifies the complexity and detail of supply

problems and how an objective is measured.

The chapter concludes with a set of requirements that make up the specification. This

specification is used to guide and align the design of the methodology so that it meets each of the

requirements before the preliminary validation.

68

3.2.4 Stage III: Discussion of the outline design for the SCM2

Stage III of the research programme discusses an outline design for the SCM2. This stage focuses

upon how the methodology will address the requirements established in the specification

detailed in chapter five. The outline design is further refined and detailed in the following stage,

both stage III and IV contribute to the following research question:

Can a methodology be developed for a simulation conceptual modelling methodology for SCM applications?

The specification detailed in chapter five discusses the requirements for an ‘effective’ conceptual

model, ‘good’ methodology and for creating conceptual models for ‘SCM’ applications. In the

context of the purpose of this thesis a number of design issues can be identified for each of the

requirements identified. These issues are discussed in turn so that a set of key concepts can be

identified that are specific to developing a SCM2. These key concepts are aligned with a general

process for conceptual modelling to identify a unique set of phases that should be included in the

methodology.

3.2.4.1 Design issues for addressing the requirements for a ‘good’ methodology

There are three design issues to address the requirements for a ‘good’ methodology. The first

concerns ‘who’ will use the methodology and ‘how’. The second is to identify a general process

for designing a conceptual model by reviewing existing contributions to synthesis a view of a

general guide. Finally, the points of entry to the methodology and discussion of the need to

iterate between stages in the methodology are considered. Therefore, the literature is examined

to address the three following questions:

Who are the participants and how should they be involved in the process of conceptual modelling for SCM applications? What is the general process that participants need to follow? What is the point of entry to a methodology for creating a conceptual model for SCM applications?

3.2.4.2 Design issues for addressing the requirements for an effective conceptual model

There are also two design issues for addressing the requirements for an ‘effective’ conceptual

model: keeping the model as simple as possible, and building a valid and credible model. The first

is addressed by discussing how a problem is stated and the model boundary formulated. There

are two issues surrounding the building a valid and credible model: in the creation (i.e.

incorporated into the steps), and to evaluate the validity and credibility of the conceptual model

itself. There is relatively little written on either aspect but there has been significant discussion in

69

the general simulation literature. For this reason, the critique centres on the applicability of the

general discussions in simulation to the conceptual modelling stage. The section addressed the

question below and contributes to some ideas that are incorporated into the methodology:

How can the methodology aid the participants to create a conceptual model that is as simple as possible and both valid and credible?

3.2.4.3 Design issues for addressing the domain specific requirements

The design issue for addressing the requirements for conceptual modeling of supply chain

problems entails identifying any domain-specific needs. The focus is on how information can be

extracted from particular sources (principally the client and the modeller). The thesis argues that

there is an opportunity to extract information from published sources to make the process of

conceptual modelling more efficient and focused. This is achieved by discussing the role of

domain knowledge in conceptual modelling in light of each of the requirements identified in

chapter four. One source is distinguished to present a great opportunity to extract domain

knowledge, namely a ‘process reference model’ that is specific to the SCM domain.

A number of process reference models for the SCM domain are critiqued to identify those that

have potential to provide the domain knowledge necessary for conceptual modelling. The

evaluation uses the criteria offered by Becker et al., (2003) who presents six main qualities for an

effective business model (i.e. correctness, relevance, economic efficiency, clarity, comparability

and systematic design). The SCOR model is selected as a reference model that offers the greatest

potential to provide domain knowledge for conceptual modelling when compared to alternatives.

The information extracted from SCOR is discussed in terms of the detailed descriptions that it

offers (e.g. business processes, performance attributes and metrics, practices) and how this would

be useful for conceptual modelling. Although SCOR has been used for simulation purposes,

particularly for designing templates for model re-use (e.g. Albores, et al., 2007) and for building

simulation applications (e.g. Barnett and Miller, 2000; Albores, et al., 2006; Chatfield, Harrison

and Hayya, 2006; Persson and Araldi, 2009) there has been little discussion of how it can be

utilised in the conceptual modelling stage.

To discuss the merits of extracting the domain knowledge from SCOR five archival case studies are

used to identify two typical supply problems that have been implemented and evaluated in the

literature. Yin (2003) states that archival case studies can be valid and of high quality, supported

by Lewis (1998) in the OM domain and Sachan and Datta (2005) for SCM applications. The two

70

supply chain problems considered are vendor managed inventory (VMI), and collaborative,

planning, forecasting and replenishment (CPFR) along with two objectives: to improve supply

chain costs and delivery performance. These archival cases were extracted from five research

contributions: Disney and Towill, 2003a, 2003b; Reiner and Trcka (2004); Chang, Fu, Lee, Lin and

Husueh, 2007; Sari (2008) and Southhard and Swenseth (2008). Using a number of archival cases

is beneficial as it shows how SCOR can be used to extract information for two improvements and

two objectives.

3.2.4.4 Presentation of outline design for SCM2

Ten key concepts are synthesised and described from the analysis of the design issues for the

SCM2. Each of the key concepts identified are linked to a general process for conceptual

modelling so that the specific phases to be included in the methodology can be established. The

inputs (e.g. information requirements) and outputs (e.g. information provided) from each phase

are discussed in light of the information that needs to be extracted from the client, modeller, and

the SCOR process reference model. The chapter concludes with an outline design of the

methodology to be detailed and refined in stage IV of the research programme.

3.2.5 Stage IV: Discussion of the detailed and refined design of the SCM2

Stage IV discusses the detail and refinements made to the outline design of the SCM2 and aligns

the design to the specification presented in chapter four. This stage also contributes to the

research question that develops a simulation conceptual modelling methodology for SCM

applications. It corresponds to the induction and iteration phases in the iterative triangulation

method.

The question to be addressed is ‘how’ a conceptual model can be created for SCM applications.

Two development cases were selected of typical and representative supply problems that are

both contextually rich and exploratory (detailed and justified in section 3.3). The cases were used

to detail and refine the methodology with illustrations to justify the choices made in the design.

The induction and iteration stage was conducted by analysing the case data based upon a set of

typical design questions/issues that were identified in phase III of the research methodological

programme. The typical design questions/issues along with the aims for the required

specification is shown in table 3.2. These correspond directly to guiding the researcher to

perform different applications in order to address the needs of the required specification. This

resulted in a list of principles and observations that influenced the design. Each of the design

choices that address the questions and issues are documented and validated in appendix A.

71

Table 3.24 Design questions and issues to address the requirements Aim Requirement Typical design questions/issues

Meet the requirements for an effective model

Keep the model as simple as possible

How can the core components of the model be identified?

How can the model boundary be determined?

How can simplification methods be incorporated into the methodology?

Build a valid and credible model

How can the accuracy of the descriptions provided from the steps be checked for correctness?

How can the accuracy of the final conceptual model be checked for correctness?

Meet the requirements of good methodologies

Procedure How can a conceptual model be created, what steps need to be followed to

incorporate the key concepts identified?

How should each of the steps be carried out?

Participation How are the participants involved in each step of the methodology?

How can information be extracted from the participants when necessary?

Points of entry How should the methodology be entered?

How should iteration occur within the methodology?

Meet the requirements for conceptual modelling of supply chain problems

Supply chain improvements

How can SCOR be used to describe a supply chain improvement?

Supply chain objectives

How can SCOR be used to describe a supply chain objective?

Supply chain setting

How can SCOR be used to identify the interconnections between components and the supply setting?

The two development cases are applied to all phases except the final phase (document and

validate) and step 6.2 (describe the model components). The validation checks within the

methodology phases are completed. The final stage re-checks each of the in-phase validation

steps and performs a hypothesis test and an expert review of the model content. The latter is

illustrated using representative examples from both of the two development cases. The rationale

for applying the cases in full up to step 6.2 is that it is at this point that the work is novel.

Step 6.1 describes the ‘domain-orientated’ model which includes a description of the actual

practices, relationships between practices at the desired scope and level of detail. This has yet to

be explored in the literature but how to describe the model components is well documented and

covered in most simulation text books (e.g. Pidd, 2004; Robinson, 2004). The methodology in

step 6.2 and the latter final validation procedure reflects existing practice. At this point the way in

which a modeller will represent the model components may depend upon their simulation

worldview or experiences using different simulation approaches. It can be argued that the holistic

validation procedure is novel but it is also a considerable area of study in its own right. The

illustrative examples are described using standard discrete-event simulation terminology (e.g.

Pidd, 2004; Robinson, 2004) for process based simulation approaches (e.g. Witness, Simul8,

Gensym e-SCOR).

3.2.6 Stage V: Preliminary validation of the SCM2

Stage V of the research programme implements the preliminary validation of the SCM2. It was

noted in section 3.1 that the refinement and the validation application should be separated to

avoid confusion, and, to provide a fresh structured walkthrough of a new supply problem after

the specification had been met. This stage concludes the ‘iterative triangulation’ process by

72

evaluating the methodology against a set of criteria to demonstrate the SCM2 is both ‘feasible’

and has ‘utility’.

To conduct this stage the SCM2 is applied to the validation case to show that it can be followed to

describe the actual practices to be included in the model (feasibility). This description is then

compared with an actual computer model to demonstrate that there are no major omissions or

significant differences (utility). Stage V addressed the final research question and identifies areas

that require future testing by addressing:

Can the methodology be followed (feasibility) and aid a user (utility) to create a simulation conceptual model for a SCM application?

The validation case only assesses the novel areas of the methodology. This means the steps are

followed up to the point that the actual practices to be included in the model (domain-specific

model) are described. It was not necessary to evaluate steps 6.2 and the final validation

procedure for the same argument presented in section 3.2.5 (e.g. due to the steps mirroring

existing practice, different worldviews). There are alternative approaches that could be

considered to complete this stage. One approach would be to survey, or interview, typical

participants to ask whether the output from the methodology is correct. An alternative includes

comparing the output from the methodology with a completed and successful computer model.

The second option is preferred as this allows a direct comparison to be made between each actual

practice to be represented and the model components and interconnections included in the

computer model.

To validate the methodology some criteria for evaluation is required. Platts (1993) suggested that

the prime aim for assessing a process framework or methodology is to determine whether the

process did provide a practical, procedural step. Platts (1993) lists three criteria for assessment

which have been posed as a series of question in Platts et al., (2001) and some sub-criteria have

been suggested in Tan and Platts (2002) shown in table 3.3. These have been discussed

specifically for a process framework for manufacturing strategy but the criteria has been used for

methodologies and different industrial contexts. This includes manufacturing action plans (Tan

and Platts, 2002), human performance modelling methodology (Baines and Kay, 2002), make or

buy process framework (Canez et al., 2000), process framework for selecting supply system

architecture (Benton, 2009).

73

Table 3.3 5 Criteria for assessing a process framework or methodology Platts (1993) criteria/ questions posed in Platts et al., (2001)

Feasibility Usability Utility

Could the methodology be followed?

How easily could the methodology be followed?

Is the methodology worth following?

Tan and Platts (2002) sub-criteria

Availability of information

Timing

participation

Clarity

Ease of use

Appropriateness

Relevance

Usefulness

facilitation

The methodology is preliminarily validated against the feasibility and utility criteria; the usability

criteria are outside the scope of this thesis. Usability cannot be assessed at the preliminary

validation stage as it requires the evaluation of how potential users of the methodology followed

the steps laid down in the methodology. The emphasise at this stage is to demonstrate that the

SCM2 could work in practice and be able to create a useful conceptual model. This is particularly

important as the methodology presented in this thesis is novel and original and little discussion

has been placed in the area of conceptual modelling for SCM applications (e.g. incorporated

simplification methods, principles). In addition to this the utilisation of SCOR for conceptual

modelling has yet to be considered so emphasis is also placed on ‘how’ it can be incorporated.

The ease in which SCOR and a process for conceptual modelling can be used to create a

conceptual model is noted as an area for future work. Although, it is demonstrated that using

SCOR with a process of conceptual modelling can potentially provide the opportunity to make the

process more focused and efficient (in section 6.4). To demonstrate that the usability criteria

have been met future tests are required with actual facilitations and participants in different

industrial settings. This is considered in a discussion of issues for future testing and some

suggestions for undertaking these tests are noted in section 8.6.

3.3 Theory building through existing case study applications

Stages IV and V both include development and validation case applications as part of the

inductive and refinement stages of an iterative triangulation approach. The previous discussion

focused upon how the analysis was conducted but not on the specific issues presented when

using case applications. There are three initial issues that need to be considered when developing

a business methodology suggested by Platts (1993):

1. the involvement of the researcher

2. the consistency of the process

3. the choice of cases to be studied

These are discussed in turn in the following section along with a description of how data was

collected from the secondary cases.

74

3.3.1 Involvement and reflexivity of the researcher

The aim of stages IV and V is to develop, refine and validate the methodology through application.

This is similar to Platts’ (1993, pg. 9) research which set out to actively apply the process that had

been developed, both to test it and refine it in practical situations. The choices between direct

observation, participation and action research was previously discussed in section 3.1.4.2. The

approach adopted is to use existing cases to apply the methodology, as it is designed, and that the

researcher can reflect and evaluate the initial feasibility and utility of the methodology.

The role of the researcher is to follow the phases identified in the outline design and identify the

specific steps that need to be conducted in order to meet the specification of requirements. The

aim was not to impose the views of the researcher on the process but to consider the design

issues that are necessary to create a conceptual model for SCM applications. This is necessary

because little guidance exists that could be observed in practice; the design issues have yet to be

considered.

Platts (1993) does note that this level of involvement may present a bias but is necessary when

refining and validating a developed methodology or process. Potential bias is reduced by

involving more than one researcher in two of the cases and one case is a traditional teaching case

used extensively for research purposes (discussed in more detail in 3.3.3). An advantage of using

a development case is that the researcher has collected data from published sources and in one

case a team of researchers (FUSION research group) to ensure independence in the application

stage. Additionally, the validation case is detached intentionally from the development cases so

that the methodology can be applied without adjustment and after the required specification is

met. The application of the methodology is conducted consistently and the design issues are

evaluated and later justified based upon showing that the methodology can be followed to create

a conceptual model. This is the focus of the following section.

3.3.2 Consistency of the process

The second research issue was the ‘choice between applying the process consistently across the

chosen companies [case applications], or, by developing and refining the process as experience

was gained’ (Platts, 1993, pg. 10). Although the first approach will allow the comparison of the

methodology the second is more appropriate as it enables the modification of the SCM2 in light of

experience gained. Platts (1993) noted this would be more robust and useful at the end of the

research. The refinements were conducted using the experience from two development cases

before a separate validation case is compared to an actual computer model. The application was

also improved by utilising the same research, although, it is recognised that different participants

75

following the methodology are required, in future testing, to improve the validity and robustness

of the findings. Additionally, each of the applications has been documented to either define the

steps in the methodology, provide the rationale behind the design decisions or to evaluate the

preliminary validation criteria.

3.3.3 Choice of supply chain application cases

One of the most important choices in the research design is the selection of supply chain

applications, number of cases and how they should be used. In terms of selecting cases there are

no clear guidelines except Platts (1993) who presents a choice between consistently finding

similar applications and validating the methodology in different situations. Eisenhardt (1989)

adds that the cases should highlight polar extremes. Other advice includes the cases should

represent all or most of the constructs of interest to maximise theory coverage within cases and

be ‘open’ to interpretation (e.g. lots of detail and description) (Lewis, 1998).

The question of the number of cases and how they should be used has been considered broadly in

the OM literature (e.g. Lewis, 1998; Meredith, 1998; Voss, Tsikriktsis, Frohlich, 2002) and wider

literature (e.g. Eisenhardt, 1989; Yin, 1994) but not in the context of developing a methodology.

In order to address this question related research can be considered in particular PhD theses that

have used application cases to develop a methodology.

A review of SCM and OM related PhD theses demonstrated different approaches and number of

cases being selected when developing a methodology. The development and refinement stage

had been separated from the validation of the methodology. For instance, considering the

number of development cases the differences include: one developmental case (e.g. Baines, 1994;

Benton, 2009) although in Benton (2009) it was used to illustrate the framework not refine it, two

developmental cases (e.g. Julka, 2008) and Lim Yan Gaun (2007) were found to have the highest

number of developmental cases with four. In terms of validation cases: Baines (1994) and Lee

Gan Kai (2007) used a single organisation, Julka (2008) used two, Benton (2009) had three and Lim

Yan Guan again had four. Some interesting observations include Julka (2008) who used the same

two cases to develop and validate. Benton (2009) placed emphasis using three cases to evaluate

the framework against Platts (1993) test criteria after illustrating the methodology with one case.

Lim Yan Guan (2007) who had the most cases explicitly noted that they were used to either

develop, or test a methodology but not applied with much depth.

Yin (1994) suggests that two or more case studies support replication and the empirical results

are considered more potent. Voss et al., (2002) contend that the fewer the case studies, the

76

greater the opportunity for depth of observation, although a multi-case study (3 – 30 cases) can

augment external validity. It can also be argued that the cases should be separated to develop

and validate the methodology. The developmental work is novel and requires a great level of

depth therefore two cases have been selected and one validation case to walkthrough the

methodology. This is different to Benton’s (2009) approach because it places a greater emphasis

on the development and refinement stage of the research.

The first development case selected is a traditional teaching case that has been described as a

good illustration of a real-life supply chain (Sterman, 1989; Disney and Towill, 2003a; 2003b), rich

environment and realistic decision rules. The second is an industrial case of a different but typical

automotive problem which is extremely detailed and complex. Both development cases allow for

all the essential features of the methodology to be applied. The industrial case provides a greater

level of detail and description that can be used to explore the many improvements and objectives

defined in the SCOR model (many of which have been piloted in the automotive sector). The

development cases cannot be argued as polar extremes but include different types of problem

and complexity. A validation case is included to walkthrough the final design of the methodology

after it had met the required specification. The validation case is selected because it offers the

opportunity to compare and evaluate any significant differences between an actual published

simulation model and that of the conceptual model. The purpose and detail of each development

and validation case are described later in the thesis and summarised in table 3.4.

Table 3.4 6 Summary of cases used to develop and validate the methodology Case Type Industry Background Sources

BeerCo D Food and beverage

Teaching case used extensively in the simulation literature (e.g. Sterman, 1989; Wilkner et al., 1991; Simchi-Levi et al., 2003; Disney et al., 2004)

Sterman (1989); MA systems (Accessed 12/04/2007); MIT Beer Game (Accessed 12/04/2007); Swiss Federal Institute of Technology, Zurich Business Game (Accessed 12/04/2007)

CarCo D Automotive

The case represents a detailed and complex supply chain problem of a simplified seat supply chain. FUSION research was funded by ESPRC.

Collaboration between Aston, Strathclyde and Liverpool in the FUSION research group

CoffeePotCo V Small kitchen appliances

Fictionalised case presented in Taylor et al., (2008) of a coffee pot manufacturer.

The main source of data providing detail from a number of manufacturers of coffee makers came from Ulrich and Pearson (1998). Other sources for cost and time data included Zeng (2003) and Zeng and Rossetti (2003).

D = Development case; V = Validation case

3.3.4 Data collection methods

The data for each of the development and validation cases were collected from various different

sources. These were used to describe and define a supply chain problem and used in this

research to create a conceptual model that can address the problem. Yin (2003) defines six

sources of evidence in case-based research that include documentation, archival records,

interviews, direct observation, participation observation and physical artifacts. All cases were

77

documented in qualitative and quantitative forms. The BeerCo and CoffeePotCo development

cases have been described in detail in the literature and have been developed by and used by a

number of researchers. They are both fictionalised cases taken from published sources.

The CarCo development case used interviews considerably with individuals from each of the

companies in the supply chain. This is important to ensure ‘investigator triangulation’ that

strengthens the validity of the detail presented in the case. The members of the FUSION research

team also directly observed the process in each of the manufacturing plants in the seat supply

chain. The data was collected by researchers that were independent of the research conducted in

this research project. This is important as the data collected was not biased by the researcher

undertaking the application of the methodology.

3.4 Limitations of research approach

The research design has a number of limitations, both in the design and most notably in the area

that the methodology has not been rigorously tested. Each of the issues identified are considered

in more detail in the further work section of the concluding chapter. The key issues include:

1. Number and selection of cases used - Three existing cases were used based upon

secondary data, two to develop (one of which is an industrial case) and one to validate

the methodology against the validation criteria. Yin (2003) suggests three cases is

sufficient for literal replication (prediction of similar results) but more cases are required

for theoretical replications (predicts contrasting results but for predictable reasons). In

particular, further applications should include original cases (using primary data) to

further refine the methodology as part of a continuing development and learning journey

until eventual theory can be claimed.

2. Future testing is required to generalise and improve the validity of the findings – The

preliminary validation only demonstrates that the methodology is initially feasible and has

utility. Further work is required to test the methodology by observing participants

independent of the researcher and in different industrial contexts.

3. Wider applicability of the methodology – The methodology developed and preliminarily

validated does not claim to be widely applicable at present. Once the process had been

tested in more industrial contexts it would be useful to improve the methodology by

asking potential users how the process can be enhanced.

78

3.5 Validity and reliability of the research

It is important to consider the validity and reliability in case based research (Yin, 1981, 1984;

Eisenhardt, 1989; Voss et al., 2002). Reliability concerns the question of whether the results of

the study are repeatable and validity concerns the integrity of the conclusions that are generated

by the research and that a study must be replicable (Bryman and Bell, 2007).

The reliability of the methodology is addressed in this thesis by following a detailed research

methodological programme, addressing the key issues when developing a business methodology.

It was argued in this thesis that the refinements of the methodology are conducted in light of

meeting the required specification and that the initial evaluation should be independent of the

refinement made when applying the developmental cases. It is noted in future work that

different potential users of the methodology is needed to test that the methodology would be

followed to deliver an appropriate output that is useful to address the context of the supply

problem.

The validity of the methodology is enhanced through the forming of a conceptual base using

existing contributions evaluated in the literature and existing cases: two developmental and one

validation case. This is supported by Eisenhardt (1989) who states that tying the emergent theory

to existing literature can enhance the internal validity as well as generalisability and the

theoretical level of theory building. Data, theory and method triangulation was achieved to

reduce any bias when establishing the conceptual base as a variety of theories and sources were

evaluated when conducting the literature review combined with archival cases. Although two of

the cases were fictionalised, one (CoffeePotCo) was based upon data extracted from published

sources that have used a variety of data collection methods observing an industrial manufacturing

environment and related shipping times and costs. In the case of the CarCo development case

data was collected from different methods (documentation, interview and direct observation) and

using different investigators.

3.6 Ethical considerations and issues

Ethical considerations are important when conducting and presenting research. This includes the

data collected direct from organisations, individuals and the various research outputs examined.

The cases used do not disclose any details which have not been authorised and all names of

organisations and their products have received name changes within each

development/validation case. The University and the researcher have full academic membership

of the Supply Chain Council so that the model can be utilised for the purpose of this project.

79

3.7 Chapter summary

The research programme and methods have been justified and described in this chapter to meet

with the research objectives and underlying questions. Firstly, a five-stage approach was

synthesised from existing research on methodologies, frameworks and processes. Stages I - III

were identified to develop and IV – V to refine and test the SCM2:

Stage I: review of existing conceptual modelling practice (chapter 4)

Stage II: forming the specification for the SCM2 (chapter 5)

Stage III: Outline design for the SCM2 (chapter 6)

Stage IV: Detailed and refined design of the SCM2 (chapter 7)

Stage V: Preliminary validate of the SCM2 (chapter 8)

The research methods adopted in each of the stages have been discussed, justified and detailed in

line with the iterative triangulation method (i.e. literature, case evidence and intuition). Three

existing cases were argued, two for the development of the SCM2 and one case used for the

preliminary validation. The refinement and validation involved the application of the SCM2 to the

cases utilising the same researcher for consistency. The refined design was compared to the

required specification formed by a review of existing practice. The preliminary validation was

used to show the initial feasibility and utility of the SCM2. Future testing is identified to generalise

and improve the validity of the initial findings. In addition, test the usability of the methodology

in different application setting and with actual users.

80

Chapter 4 Review of existing CM (Stage I)

This chapter reviews existing conceptual modelling practice in general and more specifically in the

SCM domain. The review contributes to documenting the required specification for the SCM2 and

addressing the research question:

How are simulation conceptual models created in the context of supply chain applications?

The chapter is structured to address the research question noted above by discussing:

Approaches to conceptual modelling in practice (section 4.1) – Three existing

approaches are identified in the literature. One approach that has yet to be suggested is a

methodology; it is shown that none exist for SCM applications, or in more general.

Problems encountered in simulation modelling (section 4.2) – A range of problems are

identified that are specific to the conceptual modelling stage which could be minimised if

a methodology were to be available.

Communicating and representing the conceptual model (section 4.3) – Identification of

the methods that can be used to represent and communicate a conceptual model

between the stakeholders involved in the simulation project.

Validation of conceptual models (section 4.4) – Identifies that very little guidance is

available for validating conceptual models. Existing methods for validating a simulation

model are critiqued to identify methods appropriate at the conceptual modelling stage.

4.1 Approaches to conceptual modelling in practice

This section seeks to identify the approaches that have been used for conceptual modelling in

practice. Robinson’s (2006a; 2006b) survey distinguished three basic approaches in guiding the

analyst to a definition of a conceptual model that have further been detailed in Van der Zee, Pool

and Wijngaard (2008). These include principles of modelling, methods of simplifications and

modelling frameworks. Table 4.1 lists and defines each of the approaches and provides examples

of them being used in the context of SCM applications.

81

Table 4.17 Approaches to conceptual modelling Approach to conceptual modelling

Definitions Examples in the literature

Principles Advocate an evolutionary development of models (e.g. start small and simple, adapt and extend the model incrementally)

Pidd (1999); Morris (1967); Powell (1995a; 1995b); Pritsker (1998); Law and Kelton (2000); Nydick, Liberatore and Chung, (2002)

Methods of simplification

Work the other way around by suggesting ways for model pruning. While either approaches offer relevant assistance for conceptual modelling, they do not a-priori address the creation of conceptual model, i.e. the identification of elementary model components appealing to a domain and to project stakeholders.

Morris (1967); Zeigler (1976); Ward (1989); Yin and Zhou (1989); Musselman (1994); Courtois (1985); Sevinc (1990); Innis and Rexstad (1983); Robinson (1994); Pidd (1999); Brooks and Tobias (2000); Thomas and Charpenti (2005); Chick (2006); Chwif, Paul and Barretto (2006); Brooks (2007)

Frameworks

Distinguish themselves from the above approaches by specifying a procedure for detailing a model in terms of its elements, its attributes and its relationships. Examples include the general case of systems representation and domain related cases.

Nance (1994); Guru and Savory (2004); Van der Zee and van der Vorst (2005); Robinson (2004a; 2004b; 2008a; 2008b)

Extended from the work by Robinson (2006a; 2006b) and Van der Zee, Pool and Wijngaard (2008)

Two other approaches have been omitted from the classification presented in table 4.1. The first

includes not using any formal methods for creating a conceptual model. One reason for this is

that some modellers might argue that the emergence of modern simulation software has

reduced, even removed, the need for conceptual modelling (Robinson, 2004a; 2004b). To

counteract this argument the general problems that could be avoided at the conceptual modelling

stage, if a structured approach is adopted, are discussed in greater detail (see section 4.2).

The second is a methodology that can be distinguished from a framework, as it provides a

prescribed approach, with a detailed step by step guide, and suggests relevant tools and

techniques to be used for each step to deliver a specific outcome. Similar to Van der Zee et al.,

(2008) definition of a framework they are generally designed and applied within a particular

domain. A methodology should be able to guide a user through the complex process of describing

the supply problem, identify the actual practices to be included in a conceptual model, how these

actual practices are to be represented by the components in the computer model and utilise ways

in which to represent and communicate the model. It is argued in this thesis that a detailed

methodology is domain specific due to the nature of describing and evaluating a supply problem.

No methodologies can be identified for conceptual modelling specifically for SCM application and

even in general.

4.1.1 Principles in conceptual modelling

There have been a number of research contributions that have provided a set of guiding principles

for simulation modelling (c.f. table 4.1). The majority of discussions do offer some advice or point

out the key issues when creating a conceptual model although very little could be found to be

written in a supply chain context. Pidd (1999) is one notable contribution that has been cited by

other authors (e.g. Robinson, 2004a; 2006, 2008a, 2008b; Willemain and Powell 2007). He states

82

six principles in a ‘rough guide for modelling’: Model simple, think complicated; be parsimonious,

start small and add; divide and conquer: avoid mega-models; use metaphors, analogies and

similarities; do not fall in love with data and modelling may feel like muddling through.

There is agreement by authors that the central theme and aim in simulation modelling is to create

simple models through evolutionary development (Chwif et al., 2000; Brooks and Tobias, 1999;

Brooks, 2006; Robinson, 2004a; 2008a; 2008b). Ward (1989) has provided some rationale for why

client managers may prefer constructive simplicity. He states that it is not only a convenient way

of ensuring transparent models, but also for reasons related to motivation, time constraints,

implementation and involvement of third parties.

The most difficult aspect of a conceptual modelling project and related to the principle of ‘model

simple’ is to determine the most appropriate scope and level of detail (Law, 1991). Efforts have

been made to address this difficulty by studying ways to avoid the generation of complex models

(e.g. Chwif, Barretto and Paul, 2000). Chwif et al., (2000) cites Pidd (1996) who compounds this

message by declaring that complicated models have no divine right of acceptance and lists other

researchers who have reinforced this message (e.g. Ward, 1989; Yin and Zhou, 1989; Innis and

Rexstad, 1983; Law, 2008; Musselman, 1994; Robinson, 1994 and Pegden, Shannon and Sadowski,

1995). Methods of simplification are the focus of the following section (section 4.1.2) and the

methodology incorporates a method to determine the most suitable complexity and detail in the

design chapters (chapter 6 and 7).

4.1.2 Methods of simplification

The aim of model simplification is to ‘reach a point when the study’s objectives can be addressed

by the model, then no further detail should be added’ (Robinson, 2004b pg. 87). To achieve this

there are some ideas and methods that could be embraced to simplify a model that corresponds

to two different types of simplifications presented in Brooks (2007):

Type one simplifications - simplifications that are apparent from a good knowledge of the

real system. These simplifications can be applied when choosing the initial conceptual

model.

Type two simplifications – those that are derived from analysis of the model, such as

sensitivity analysis, or detailed examination of the model behaviour and could not be seen

easily without such analysis.

Conceptual modelling concerns ‘type one simplification’ and should avoid as much as possible the

need for ‘type two simplifications’. It is generally regarded that a conceptual model needs to be

83

created before a model is implemented. The problem resides in what a modeller constitutes as a

conceptual model, how rigorous the analysis was undertaken and how it was adequately

documented. Another major factor is that decisions at the conceptual modelling stage can only

be considered subjectively in relation to the ‘probable’ impact upon model accuracy. Type two

simplifications are as a result of direct experimentation on a computer model. This is, of course,

developed from the description of the conceptual model. At the conceptual modelling stage

there are likely to be decisions about the scope and detail that would be difficult for a modeller to

qualify. In these cases the only method available for making such decisions is to use a prototyping

method (e.g. Powell, 1995a; 1995b; Pidd, 1999; Robinson, 2004a; 2004b). This can be classed as a

‘type two simplification’ but only on a subset of the model.

The literature provides a vast amount of advice and methods on how to simplify a model. Table

4.2 lists each of the different types of advice and methods on how to simply a model and

references each corresponding author. The contributions can be categorised by methods and

techniques for simplifying models (e.g. Morris, 1967; Zeigler, 1976; Robinson, 1994; Chwif, Paul

and Barretto, 2006), common advice on model simplifications (e.g. Ward, 1989; Brooks, 2007) and

some guiding principles and criteria on model simplification (e.g. Ward, 1989; Courtois, 1985;

Pidd, 1999). The table also adds additional value by distinguishing between the advice and

methods that are applicable for type one and type two simplifications. It shows that the majority

of advice and methods are applicable to type one simplification and thus are candidates for

inclusion in a methodology.

84

Table 4.28 Research contributions on simulation model simplification (advice and methods)

Advice on model simplification/method

Typ

e o

ne

sim

plif

icat

ion

s

Typ

e t

wo

sim

plif

icat

ion

s

Mo

rris

(1

967

)

Zeig

ler

(19

76

)

War

d (

19

89

)

Yin

an

d Z

ho

u (

19

89)

Mu

sse

lman

(1

994

)

Inn

is a

nd

Re

xsta

d (

198

3)

Ro

bin

son

(1

99

4)

Pid

d (

19

99)

Bro

oks

an

d T

ob

ias

(20

00)

Ro

bin

son

(2

00

4a;

200

4b

; 2

00

6; 2

00

8a;

20

08b

)

Tho

mas

an

d C

har

pe

nti

(2

00

5)

Ch

ick

(20

06

)

Ch

wif

, Pau

l an

d B

arre

tto

(20

06

)

Bro

oks

(2

007

)

Modelling process: start simple then add complexity and detail

X X X X X X X X X X

Make variables into constants

X X X X

Aggregate variables/group components with certain shared characteristics

X X X X X X X X X X X

Restrict/eliminate variables X X X X X X X X X X

Strengthen assumptions and restrictions

X X

Exclude/drop unimportant components in the model

X X X X X X X X X X

Use random variables to depict parts of the model

X X X X X

Quantify relationships (connections) between variables

X X X X X X

Limit the amount of uncertainty in the model/Reduce randomness

X X X X X X

Assume a well-defined objective function or set of decision criteria/ include only output measures of interest (experimental frame)

X X X X X X X X

Split models (divide larger models into smaller components)/ use more than one model

X X X X X

Using analogies X X X

Proper use of data X X X

The majority of the findings presented in table 4.2 are offered in general and are not specific to a

particular domain although some discussions reside within the manufacturing literature (e.g.

Brooks and Tobias, 2000; Thomas and Charpenti, 2005). The advice does not constitute a guide,

or set of procedures, to aid in the creation of a conceptual model. For example, there are some

important questions identified by Robinson (2008a; 2008b) that need to be addressed to build a

simple model - When should more detail be added? When should elaboration stop? It can be

argued that there is a difference between offering a set of principles, or advice, and guiding

someone through the process.

The other key area includes reducing the scope and level of detail. This can be achieved by either,

removing components and interconnections that have little effect on model accuracy, or by

85

representing more simple components and interconnections while maintaining a satisfactory level

of model accuracy (Robinson, 2004b). Some of the less cited advice on model simplification

would also be extremely useful in a supply chain context. For instance, supply chains are

inherently complex and simulation is a good method to examine their behaviour. Methods that

are able to reduce complexity (e.g. interconnections between actors and business processes),

behaviour and uncertainty in a model would be extremely useful.

4.1.3 Modelling frameworks

A modelling framework specifies a set of procedures for detailing a model in terms of its

elements, its attributes and its relationships (Van der Zee et al., 2008). The procedure laid down

in a framework usually provides a conceptual structure to follow in order to complete the purpose

of what it is set out to do.

There have been some notable attempts to define a framework for conceptual modelling within

particular domains, or purposes. The earliest work can be found in the military domain by

Shannon (1975) and more recently, Pace (1999, 2000a; 2000b) has explored a similar approach

that depicts four key stages. Nance and Arthur (2006) identify the potential to adopt software

requirements engineering approaches for simulation model development. Additionally, Brooks

and Tobias (1996) propose a framework for conceptual modelling but do not expand on the idea.

Two contributions have expanded in more detail on a process framework for conceptual

modelling. This includes Robinson (2004a) who described in his text a general process framework

for conceptual modeling. Also within the SCM domain Van der Zee and Van der Vorst (2007) have

defined an object-orientated modelling framework. The text ‘Simulation: The Practice of Model

Development and Use’ by Robinson (2004b) provided a large part of the motivation for this

research study.

The framework proposed by Van der Zee and Van der Vorst (2007) is aimed at an object

orientated implementation of the computer based simulation model (Robinson, 2008a; 2008b).

The authors focus on a simulation reference model and library of building blocks to be used in a

simulation tool. There is no process described on how to create a conceptual model, rather it

provides a modelling language and simulation tool for exploring supply chain problems. The tool

is similar to that provided commercially, such as Gensym e-SCOR (Barnett and Miller, 2000) and

SDI supply chain builder (Phelps, Parsons and Siprelle, 2001).

Only Robinson (2004a) provides detail on the stages of a conceptual modelling project. Even in

this case Robinson (2006) points out that no guide exists to aid a modeller through how to bring a

conceptual model into existence. The work by Van der Zee and Van der Vorst (2007) also does

86

not provide a guide on how to create a conceptual model. For instance, the modeller will still

need to decide which modelling blocks to use from a predefined library and how they are to be

configured. Therefore it can be concluded that the major weakness of existing approaches is that

they do not address the ‘how’ and do not comprehensively incorporate existing practice, which

can aid in the creation of a conceptual model for SCM applications.

4.2 Problems encountered in simulation modelling

There are many problems encountered in simulation modelling that would benefit from a greater

understanding and usage of following a structured approach to the creation of a conceptual

model. The problems encountered in general for simulation have been discussed in detail in the

literature (e.g. Law and McComas, 1986; Sadowski, 1989; Musselman, 1994; Ulgen, Gunal and

Shore, 1996; Carson, 2004). Table 4.3 presents some of these that may relate to, or would have

been influenced by, the conceptual modelling stage of a simulation project.

Table 4.39 Potential pitfalls in simulation related to conceptual modelling

Potential pitfall related to conceptual modelling

Source

Law

an

d

McC

om

as (

19

86

)

Sad

ow

ski (

19

89

)

Mu

ssel

man

,

(19

94

)

Ulg

en e

t al

.,

(19

96

)

Car

son

, (2

00

4)

No clearly defined goals and purpose that should be kept in mind for the whole study X X X X

No common understanding on the project scope and goals, questions to be addressed, and even not to be addressed, communicated between the stakeholders in the study

X X X X

Involve key decision makers X

Too much detail in the model X X

Allowing complexity to creep into the model X X X

Not defining the ‘real’ problem adequately X

Too much time spent concentrating on the model building rather than focusing on the problem X X

Ensure that the model is verified and validated (in the context of the computer model) X X X

Document the model and supply evidence of any justifications made X X X

Not knowing when to stop X

The value of identifying the potential pitfalls in simulation is to understand how they can be

avoided at the conceptual modelling stage. A methodology that aids a user in the creation of a

conceptual model should incorporate concepts and procedures that can avoid the pitfalls

outlined. This includes:

Ensuring that the ‘real’ problem is adequately described

Facilitate communication between the various stakeholders in the project

Determine the model content to address the model objectives (e.g. correct scope and

detail)

87

Incorporating procedures for validating the conceptual model (little discussion was

identified regarding the validity of a conceptual model being a pitfall, all discussions

related to the computer model, this is addressed in section 4.4)

Documentation of the description of the model to be developed so that the model can be

represented and communicated

Defined and structured set of steps to guide a user through the process and knowing

when to stop

One of the pitfalls noted above concerns what has been regarded as the central aim of conceptual

modelling: determining the complexity and level of detail. Chwif et al., (2000) provide some

technical and non-technical (related to human nature) reasons for increasing the complexity of a

model. These reasons are listed in table 4.4, along with some comments and considerations of

various issues that might arise when evaluating supply chains using a simulation approach. The

main consideration that can be identified is that the majority of problems encountered are

domain specific (e.g. supply chain actors, processes and activities). This provides some further

justification for a domain specific methodology that can address these needs.

Table 4.410 Reasons for increasing complexity (some consideration in the SCM domain) Reasons for increasing complexity (Chwif, Barretto and Paul, 2000)

Consideration of some issues in supply chain simulation

Non-technical

1) The show-off factor (e.g. incorporating unnecessary detail or features to impress stakeholders)

Difficulties include too many actors represented in the model, supply chain processes and activities that do not improve the accuracy of the model.

2) Include all syndrome (e.g. insecurity of models in what should be included)

The actors, processes to be included in the model and which inputs can be simplified.

3) Possibility factor (e.g. making use of computer power)

There are some advanced simulators available for simulation modelling (e.g. Gensym e-SCOR). In the case of e-SCOR it includes a template of all critical SCOR processes and performance metrics. In a supply chain problem it is not necessary to use all the functionality for a given problem but the additional functionality may lead to this principle being disregarded

Technical

1) Lack of understanding of the real system

Inability to agree on the conceptual model requirement between stakeholders in the project. In particular in a supply chain context it is difficult to obtain data from suppliers in a supply chain due to commercial reasons.

2) Inability to model correctly the problem (conceptual model)

Building the model ‘as close to reality as possible’ is difficult in supply chain management as the processes stretch across organisational boundaries and functions. Only the critical processes and workflows between these processes need to be included.

3) Inability to translate or code correctly the conceptual model into a computerised model or lack of simulation

The modeller not being totally acquainted with the functionality of simulation software or lack of good programming skills. Additionally, general simulators (e.g. Witness, Simul8) have been used for manufacturing problems but supply chain problems involve different set of entities, relationships and modelling logic

4) Unclear simulation objectives Poorly defined objectives lead to over complex models (Innis and Rexstad, 1983; Yin and Zhou, 1989)

4.3 Communicating and representing the conceptual model

A conceptual model can be represented in different ways (e.g. component list, process flow

diagram, logic flow diagram) and is usually communicated as part of a simulation project

88

specification. The simulation project specification is the key means of communicating the

conceptual model, with the various stakeholders in the simulation study, on how the model

design reflects the context of the modelling project in the real world (Robinson, 2004a; 2004b).

Essentially, the specification not only includes the conceptual model but also contains project

related information. The project management outcomes are not considered in the scope of this

thesis, emphasis is placed upon the creation of a conceptual model.

There have been other terms used for documenting the outputs of the earlier stages of a

simulation project. It is important that these should not be confused with the common definition

presented in this thesis on what constitutes a conceptual model (C.f. section 2.4). Earlier work in

defining simulation steps may not have necessarily used the term ‘conceptual model’ (e.g. Law

and McComas, 1991; Nordgren, 1995). Musselman (1994) is one of the earliest contributors who

described the need for ‘model conceptualisation’. It was after this period that these terms

appeared more commonly in work that describes the different stages in a simulation project (e.g.

Robinson and Bhatia, 1995; Balci, 1997; Law, 2003).

In the earlier work predating the term ‘conceptual model’, Law (1991) described an ‘assumption

document’ which is still in use today but has a more specific meaning. The assumptions

document becomes the specification for the actual computer model (Nordgren, 1995). It includes

information on the system operating procedures and control logic data to specify model

parameters and input probability distributions (Law and McComas, 1991). This is beyond the

scope of what is now known as conceptual modelling. It can be more clearly aligned with the

documentation at the ‘model coding’ stage, which directly precedes model building and is

conducted after the conceptual model has been created.

4.3.1 Simulation project specification

Robinson (2004a; 2004b) details what should be included in a simulation project specification.

This includes the background to the simulation study, objectives of the study and the rationale for

addressing the problems using a simulation approach, data requirements, time-scales and

milestones for the study and estimated costs (Robinson, 2004a). The specification is a ‘live’

document which is continuously updated in light of some improved understanding of the real

system, or how it can be represented in a computer model.

Other than Robinson (2004a; 2004b; 2006; 2008a; 2008b) it is difficult to identify any evidence of

a ‘simulation project specification’ being described, or cited, in the simulation literature. This

does not necessarily mean that they are not used in practice. It is expected that there needs to be

89

some means of communication between the modeller and the client on the purpose of the

project, which should contain details of the model to be developed. The majority of the literature

has focused on how a conceptual model can be represented, rather than a document which can

be circulated between the stakeholders in the project. The focus of this thesis is primarily on the

creation, documentation and validation of the conceptual model, rather than the project-related

aspects of a conceptual modelling project.

4.3.2 Representing the conceptual model

The conceptual model can be documented by one or more methods depending upon how the

modeller wishes to represent the content of the model. These representations can be included in

the simulation project specification along with any written text that describes the model and

provides rationale for the decisions made in its conceptualisation.

Wang and Brooks (2007b) surveyed simulation users asking which methods are used to document

a conceptual model. They identified, in order of preference, those included: process flow

diagram, list of assumptions and simplifications, logic diagrams, component lists, activity cycle

diagrams, UML (unified modelling language), text description and visual display. Table 4.5 lists

each of these methods in order of preference, adds a description of their purpose and provides

examples of them being used for SCM applications using a simulation approach.

90

Table 4.511 Methods used to document CM with examples in the SCM literature Documentation

method Percentage of participants

Purpose Examples in the SCM literature

Process flow diagram

63%

Useful way to understand any business process and show interrelationships between activities in a process (Greasley, 2009)

Hines and Rich (1997); Naim, Childerhouse, Disney and Towill, (2002); Persson and Olhager, (2002); Reiner and Trcka (2004); Hwarng, Chon, Zie and Burgess, (2005); Van der Zee and Van der Vorst (2007); Taylor, Love, Weaver and Stone (2008)

List of assumptions and simplifications

57% A list of assumptions and/or all simplifications made during the process of creating the conceptual model

Bhaskaran, (1998); Petrovic, Roy and Petrovic (1998); Persson and Olhager, (2002); Hwarng et al., (2005)

Logic diagram 31%

Uses the same standard symbols used in process flow diagrams to represent the logic of the model rather than the process flow (Robinson, 2004a; 2004b)

Bhaskaran, (1998); Chan and Chan (2005); Hwarng, et al., (2005)

Component list 22% Lists the components to be included in the model content with some description

Bhaskaren, (1998); Lee et al., (2002); Changchien and Shen (2002)

Activity cycle diagram

19%

An activity cycle diagram are used in discrete event simulation to develop the structure of a model (Hill, 1971) by identifying how various entities in the model interact through simulated time.

Changchien and Shen (2002); Ryan and Heavey (2006); Van der Zee and Van der Vorst (2007)

UML 14% Language for modelling object systems based on object-orientated modelling methods (Evans and Clark, 1998).

Alfieri and Brandimarte (1997); Gunasekaran, (1999); Biswas and Narahari (2004)

Text description 5% Text description of the conceptual model Mason-Jones and Towill (1999); Petrovic (2001); Jammernegg and Reiner (2007); Taylor et al., (2008)

Visual display 2% A diagram or figure which displays the conceptual model graphically

Non-identified

Other 8% N/A N/A

None 5% N/A N/A

*Respondents listed more than one method

Source: Extended from Wang and Brooks (2007b) survey of simulation users

Many examples could be identified in the SCM literature of a model being described using a

process flow diagram and a description of the assumptions and simplifications incorporated into a

computer model. The popularity of a process flow diagram may be due to the widespread

applicability of the method within the field of operations and supply. Additionally, it is often

regarded necessary for publications to provide some rationale on how the model was simplified

(although most contributions did not provide an explicit list).

It was difficult to find many examples in the SCM literature of the other documentation methods

being included in research papers, except in the case of activity cycle diagrams. These have been

used as a specific means for representing discrete-event simulation models (Hill, 1971) and have

been described in detail in Pidd (1998; 2003). Robinson (2004a; 2004b) notes that activity cycle

diagrams share some characteristics and sit between process flow diagrams and logic flow

diagrams as all three are visual representations and provide, in part, the logic of a model. In the

case of logic flow diagrams there is some commercially available software which supports the

method (e.g. IGrafx Process 2000, an example is shown in Albores et al., 2006) and activity cycle

diagrams can be used when programming a model but not necessarily if using a simulation

package.

91

It is clear that methods are used to represent a conceptual model in SCM applications using

simulation. For instance, Wang and Brooks (2007b) indicate that only 5% of the respondents

answered with a response that stated no documentation was used. However, it can be noted that

there is little attempt in research papers to describe and justify a conceptual model which should

receive greater attention to improve the rigour of SCM simulations studies in the future (Manuj et

al., 2009).

4.4 Validation of conceptual models

Validation of simulation models has received a lot of attention in the literature. A general view of

model validation has been offered by Balci (1994, pg. 2) who states that it refers to ‘substantiating

that the model, within its domain of applicability, behaves with satisfactory accuracy consistent

with the study objectives’. Alternative definitions have focused upon establishing ‘confidence’ in

emulating the real system (e.g. Love, 1980), building it ‘right’, or a ‘correct’ model, for the

purposes at hand (e.g. Pace, 1999; Sargent, 2005; 2008) and similar to Balci (1994) some have

been more specific by stating that in relation to the terms used it should be ‘significantly accurate’

(e.g. Carson, 1986; Robinson, 1997).

There have been two prominent focuses in the literature in the area of validating simulation

models. For instance, Love (1980) suggests that ‘confidence’ in a model utility is a gradual task

throughout a simulation project as well as at the final testing phases. These views are also

notable in two recent contributions presented by Law (2008) and Sargent (2005; 2008) at the

Winter Simulation Conference. Sargent’s (2005; 2008) discussion concentrates predominately

upon final testing techniques, whilst Law (2008) presents some key final stage validation

techniques and aligns ideas for building valid models with a traditional view of a simulation

project. The validation techniques presented by Sargent (2005; 2008) are claimed to describe the

majority of methods, although he notes, that some differences in definitions may exist (earlier

work has been founded upon key contributions such as Conway, (1963); Herman, (1967) and

Zeigler, (1976) and has been updated on numerous occasions since 1979. Both papers reflect

some of the more recent key contributions in the area (e.g. Carson, 1986, 2002; Law and

McComas, 2001; Banks et al., 2005).

The validation of conceptual models is one area of the literature in which there is little discussion,

especially on what constitutes conceptual model validation and which validation tests are

applicable. This is surprising; as Robinson (2008a; 2008b) asserts that the need for conceptual

model validation is well documented and references Ward (1989) and Sargent (2004), in support

92

of this view. More recently, and in the context of SCM simulation, this view is also shared by

Manuj et al., (2009) as an essential way in which to improve the rigour of simulation studies.

There have been some attempts at defining what constitutes conceptual model validation and

also discussions of existing methods that have been applicable. For instance, Sargent (2005, pg.

135) suggests that the ‘validation of a conceptual model concerns the determination that the

conceptual model is reasonable and correct for the intended purpose of the model’. Robinson

(2006, pg. 6) takes a similar view that a conceptual model should be ‘sufficiently accurate for its

intended use’. This is in line with existing convention on model validation but the area in which

there is a lack of clarity and consensus is in terms of which methods are applicable to fulfil these

definitions. The main reason for this is that not all the methods listed and described by Sargent

(2005; 2008) and those authors before him (e.g. Banks, Gerstein and Searles, 1988; Kleijnen,

1999; Balci, Nance, Arthur and Ormsby, 2002; Carson, 1986, 2002; Law and McComas, 2001;

Banks et al., 2005) focus upon the evaluation of a computer model results and/or its behaviour.

Two methods have been suggested by Sargent (2005; 2008) for validating conceptual models.

These include ‘face validity’ and ‘traces’. It must be noted that there is no support other than in

Sargent (2005; 2008) for the ‘traces’ method and only Sargent himself uses the term ‘face

validity’. Sargent (2008, pg. 162) defined these validation tests in relation to the conceptual

modelling stage as:

Traces – ‘tracking of model entities through each sub model and overall module to

determine if the logic is correct and if the necessary accuracy is maintained. Any errors

found in the conceptual model results in revisions and re-iteration through the validation

step’.

Face validity – ‘individuals knowledgeable of the real system being observed evaluate the

conceptual model to determine if it is correct and reasonable for its purpose (e.g.

examining the flowchart or graphical model, or set of model equations)’.

The traces method requires the relationships between entities to be defined in detail. It is more

commonly associated with the verification procedures for coded models. Using Sargent’s (2005;

2008) definition of what constitutes a conceptual model (C.f. section 2.5) he allows for the

detailed logic to be developed. This is outside the scope of the definition of a conceptual model

presented in this thesis and more widely in the literature (e.g. Pace, 1999; Robinson, 2008a;

2008b). What is clear is that both Sargent (2005; 2008) and Law (2008) distinguish between

‘problem definition’ resulting in a conceptual model and that of the specification that assures that

93

the software design, and any programming, implements the conceptual model satisfactorily in the

computer system. This detail is specific to a particular software or programming language. For

this reason alone the tracing method cannot be conducted at the conceptual modelling stage.

There is a consensus in the limited number of contributions that highlight the need to involve

‘subject matter experts’ in the process of conceptual modelling and to determine the

‘correctness’ of the conceptual model as an end validation step (e.g. Pace, 1999; Robinson, 2006;

Law, 2008; Sargent, 2005; 2008). Sargent (2005; 2008) is the only author to suggest specifically

‘face validity’ in the context of conceptual modelling. Although, the other authors previously

cited do not use this term, they recognise that there is a need to obtain feedback from subject

matter experts on the conceptual model by checking that it is ‘sufficiently accurate for its

intended use’. Therefore, there is an imperative need to involve the relevant stakeholders in the

process (discussed in detail in section 5.1 and 6.1) and an expert review as a final validation test.

Earlier contributions have concentrated on using hypotheses independent of the model’s

programmed structure (e.g. Hermann, 1967, Zinnes, 1966). Love (1980, pg. 405) presents a view

of hypothesis testing in light of Hermann’s (1967, pg 223) discussion, as an “examination of

connections between system elements, so as to determine whether the model reproduces those

relationships”. For instance Hermann (1967, pg 223) states that ‘If X is observed to bear a given

relationship to Y in the observed universe, then ‘X should bear a corresponding relationship to Y’

in a valid operating model’. Hermann (1967) notes that the hypotheses made about the

relationships and entities could be either ‘stated as researchable hypothesises’ (a rationalist

view), or even ‘empirically verifiable propositions defined from them’ (an empiricist view).

Interestingly, Balci (1986) cites Gass’ and Thompson’s (1980) term ‘theoretical validity’ and notes

that this has been later used by Sargent (1985) under the name of ‘conceptual model validity’.

This discussion has shown that only the ‘theoretical validity’ of a conceptual model can be tested

at the conceptual modelling stage, as all other tests require either a computer model, or the

model logic to be defined in detail. Hermann’s (1967) term ‘hypothesis validity’ can be used to

avoid any confusion in the literature and there is a fundamental need to have an ‘expert’ review

of the conceptual model (e.g. individuals knowledgeable about the actual system being observed).

94

4.5 Chapter summary

Chapter four has identified and reviewed existing practice of conceptual modelling for SCM

applications. This corresponds to completing stage I of the research methodological programme

and addresses the research question that considers how simulation conceptual models are

created in the context of supply chain applications. This has included, identifying the various

different approaches to conceptual modelling in practice, reviewing the problems encountered in

simulation modelling which could benefit from a greater understanding of conceptual modelling,

different means of communicating and representing a conceptual model and identifying ways in

which a conceptual model can be validated.

The key findings identified in this review are that there is no methodology for creating a

conceptual model. There are many guiding principles offered in the simulation modelling

literature that relate to the conceptual modelling stage, methods for simplification and a limited

number of frameworks. A review of potential pitfalls (or problems) in simulation studies could

benefit greatly from successfully completing the conceptual modelling stage as part of a

simulation project. There are numerous ways of representing a conceptual model and it is

generally communicated as a significant component of the simulation project specification.

The chapter also argues the importance and need to validate a conceptual model. In this area

there is consensus about the importance and need for validating a conceptual model, but this has

yet surfaced into a significant discussion, of which validation methods may be relevant in the

conceptual modelling stage. The discussion proposed a hypothesis test as a credible means of

validating a conceptual model, coupled with the need to have an expert review.

The review of existing practice is intended to not only demonstrate that no methodologies exist in

the context of the purpose of this thesis, but to consider some of the issues that might need to be

included in the methodology to be developed. The next chapter builds upon the existing practice

to identify the required specification for the methodology to be developed in this thesis.

95

Chapter 5 Forming the specification for the SCM2 (Stage II)

Chapter five delivers stage II of the research programme by forming a specification for the SCM2.

It explicitly addresses the research question which seeks to identify the required specification for a

SCM2. Stage one (detailed in chapter four) along with this stage satisfies the first research

objective: A documentation of the required specification for a methodology for creating simulation

conceptual models for SCM applications. The specification is determined by considering three

different requirements:

Requirements for creating an effective conceptual model (section 5.1) – The qualities

that a conceptual model can be evaluated against are reviewed (e.g. Willemain, 1994;

Brooks and Tobias, 1996; Robinson, 2004a; 2004b; 2006; 2008a; 2008b; Brooks 2006) and

the fundamental need to ‘keep the model as simple as possible’ is argued.

Requirements for a ‘good’ methodology (section 5.2) – The characteristics of a ‘good’

methodology are reviewed using Platts (1994) general criteria and a review of existing

methodologies in the SCM and OM domain (e.g. Checkland, 1981; Platts and Gregory,

1990; Bennett and Forrester, 1993; Agarwal and Shakar, 2002; Naim et al., 2002; Bolstorff

and Rosenbaum, 2003; Blackhurst, Wu and O’Grady, 2005). Lessons are drawn for

developing a methodology for conceptual modelling.

Requirements for conceptual modelling of supply chain problems (section 5.3) –

Identification of the domain specific needs for conceptual modelling of supply chain

management related problems (i.e. the range of improvements, range of supply chain

performance measures and setting of supply chain problems).

The specification detailing the requirements that the methodology to be developed must meet is

documented at the end of this chapter (section 5.4). These requirements are compared to the

methodology that has been developed and refined with two typical SCM applications to ensure

that each requirement set out in this chapter are met.

5.1 Requirements for an ‘effective’ conceptual model

It is important to detail some requirements for creating an effective conceptual model. This

section considers the four requirements for a conceptual model using Robinson’s (2004a; 2004b;

2008a; 2008b) criteria, and the fundamental need to keep the model as simple as possible (as

discussed in section 4.1). The purpose of this section is to identify how a methodology can play a

role in creating a conceptual model that meets the criteria and is as simple as possible for the

purpose at hand.

96

5.1.1 Four requirements of a conceptual model

Robinson (2004b) identifies four requirements to be considered when creating an effective

conceptual model. These requirements include the validity, credibility, utility and feasibility of a

conceptual model. Table 5.1 lists each of these four requirements and notes the definition

provided by Robinson (2004b). It also demonstrates that Robinson’s requirements have been

synthesised from previous related discussions. In particular, Willemain (1994) lists five qualities

for a good model and Brooks and Tobias (1996) present a more comprehensive and detailed list of

eleven performance criteria. Both Willemain (1994) and Brooks and Tobias (1996) discussions are

discussed in terms of the simulation project as a whole. Only Robinson (2004a) has discussed the

specific requirements of a conceptual model.

Table 5.1 Four requirements for a conceptual model Four requirements of a

conceptual model Definition

(provided by Robinson, 2004b) Other notable contributions in

support of the requirement

Validity A perception, on behalf of the modeller, that the conceptual model will lead to a computer model that is sufficiently accurate for the purpose at hand

Willemain (1994); Kleijnen (1995); Brooks and Tobias (1996); Law (2008)

Credibility A perception, on behalf of the clients, that the conceptual model will lead to a computer model that is sufficiently accurate for the purpose at hand

Robinson (2004b); Law (2008)

Utility A perception, on behalf of the modeller and the clients that the conceptual model will lead to a computer model that is useful as an aid to decision-making within the specified context

Willemain (1994)

Feasibility A perception, on behalf of the modeller and the clients, that the conceptual model can be developed into a computer model

Willemain (1994)

Extracted from Robinson (2004b, pg. 67) along with a note of other contributions in support of each

Willemain (1994) survey of modelling experts identified ‘validity’ as the most important

requirement of a simulation project. This was followed by utility, feasibility and then, least

mentioned, was credibility (termed ‘aptness’ for the client’s problem). Surprisingly, credibility

received little attention but both this criterion and validity concerns the ‘probable’ accuracy from

the perspective of the modeller (validity) and the client (credibility). The question that needs to

be addressed is whether the conceptual model is an accurate representation of the system under

study (Kleijnen, 1995). More specifically, Willemain (1994) notes that this means that the

conceptual model contains all the essential features (e.g. scope and level of detail).

Utility is different from both the credibility and utility criteria as it determines whether the actual

model is ‘useful’. Robinson (2004a; 2004b) points out that different conceptual models could be

designed which would meet the validity and credibility requirements (it is sufficiently accurate)

but may hold different degrees of ‘utility’. This may affect whether the model is understandable

by both the client and the modeller, may not be economic in terms of data collection and

computation, and there are issues concerning the accessibility to those who may wish to use the

model (Gass, 1983).

97

Feasibility concerns whether the conceptual model can in fact be developed into a computer

model. More specifically, this concerns the time and cost to build the model (including data

collection, verification and validation), running the model, analysis of the results of the model and

any hardware requirements (e.g. computer memory) of running the model (Willemain, 1994;

Brooks and Tobias, 1996). At the conceptual modelling stage only a subjective assessment can be

made in relation to how the conceptual model is to be developed into a computer model.

The methodology to be developed can be used to build valid and credible models. Validity and

credibility can be incorporated into the methodology as the aim of the process is to create an

‘accurate’ representation of the problem at hand. The ‘probable’ accuracy of the model is

improved by formulating the model boundary and determining the most appropriate level of

detail to address the model objectives from the perspective of both the modeller and client.

Feasibility and utility concern the end output: the description of the computer model to be

developed. This description is determined after an accurate model boundary and level of detail

has been formulated. It is only at the final stage questions, about how ‘useful’ and ‘feasible’ the

description is to lead to a computer model, can be addressed. Additionally, the methodology is

itself evaluated in the preliminary validation against the Platts (1993) ‘utility’ and ‘feasibility’

criteria. For these two reasons, the requirement is limited to only building a valid and credible

model in addition to keeping the model simple.

5.1.2 Building ‘valid’ and ‘credible’ models

Law (2008) contends that there are many ideas for building valid and credible models throughout

the duration of the whole simulation project. Three of the ideas relate specifically to a successful

completion of the conceptual modelling stage. Law (2008) does not use the term ‘conceptual

model’ but describes that the first stage of a simulation project is to ‘formulate the problem’

followed by the ‘documentation of an assumptions document’. The three issues relating to

formulating the problem include:

1. Formulating the problem precisely

2. Interacting with the decision-maker on a regular basis throughout the simulation project

3. Interview appropriate subject matter experts

These are important considerations when designing a methodology for conceptual modelling,

particularly to address the domain specific needs for SCM applications. The complexity of supply

problems, needs and role of stakeholders in the process present a unique set of requirements

specific in the area of SCM. An ill-defined problem will lead to a model that may have an

98

inappropriate scope and level of detail. Additionally, not involving decision-makers and

individuals who hold knowledge about the real system will affect the actual validity of the

computer model. Therefore, when designing a methodology for creating valid conceptual models

of supply chain applications, there is a need to explicitly address the need to formulate the

problem based upon an understanding of supply chain problems and the role of stakeholders in

the process.

5.1.3 Fundamental need to keep the model ‘simple’

It has previously been argued in section 4.1 that there is consensus in the simulation community

that the central aim is to ‘keep the model as simple as possible to meet the objectives of study’

(Robinson, 2004b, pg. 66). The amount of research on the topic was shown to be great for both

guiding principles in modelling (section 4.1.1) and methods of model simplification (section 4.1.2).

The majority of which were shown to be applicable at the conceptual modelling stage.

There are a number of advantages cited for developing simple models which include ease of use

and functionality (e.g. Little, 1970; Innis and Rexstad, 1983; Salt, 1993; Chwif et al., 2000;

Robinson, 2004a; 2004b) and greater transparency (e.g. Little, 1970). For instance, a simple

model is easier to code, validate and analyse, easier to ‘change’ and the time can be seriously

reduced (Chwif et al., 2000). In terms of the transparency of a model, it needs to be simple to

understand, at least in outline form and should be easy to manipulate and control (Little, 1970).

This is desirable because trust is important between the modeller and the client. This is easier to

establish if the client can appreciate the overall working of the model and understand what the

model can and cannot do and why (Pidd, 2003).

There must be a balance between the credibility of a model and its simplicity (Chick, 2006).

Brooks and Tobias (1996) point out that if a model is too simple it may be unrealistic and its

results will be, at best, of little use, and at worst, misleading. Two reasons for this may be due to

the assumptions made about the system and the exclusion of behaviours and/or model

components that will have an effect on model accuracy. The methodology must, therefore,

provide a mechanism for deciding the most appropriate complexity and level of detail without

making the conceptual model too simple or complex.

5.2 Requirements for ‘good’ methodologies

A methodology can be defined as a repeatable process that can be used, and reused, any number

of times and is made up of best practices, rules, guidelines and templates (Murch, 2005). The

process specifically guides a user to an approach and solution that is appropriate to their context

99

(Checkland, 1981). In the case of this research, the context is the creation of a conceptual model

for supply chain applications. A methodology would therefore provide a step by step procedure

on how to create a conceptual model in a structured way that can be repeated to obtain more

predictable results each time.

Section 4.1 identified that no methodologies exist for creating conceptual models. However, the

characteristics of methodologies can be established by reviewing existing literature that has

presented methodologies to deal with real-world complexity. Methodologies have been

suggested for general problem solving such as ‘hard’ systems approaches often termed ‘systems

engineering’ and ‘soft’ system approaches (e.g. Checkland, 1981). In the context of operations

management, Platts and Gregory (1990) presented a manufacturing audit in the process of

strategy formulation and Bennett and Forrester (1993) suggested a methodology for the design

and implementation of market-focused production systems. Specifically in the SCM domain,

methodologies have focused on diagnosing and improving supply chain performance (e.g.

Agarwal et al., 2002; Naim et al., 2002; Wu and O’Grady, 2004; Bolstorff and Rosenbaum, 2003)

and selecting supply chain configurations (e.g. Wang et al., 2004; Blackhurst et al., 2005).

Platts (1994) suggested the desirable characteristics for successful strategy formulation

methodologies. These include procedure, participation, project management and point of entry,

which are broken down in table 5.2. The procedure (or guide) is the key requirement of a

methodology which should embed participation, project management and points of entry. This

includes suggesting the necessary phases in the methodology and the associated steps. For each

step in the methodology it should suggest what information is required and what information it

provides with the use of suggested tools and techniques to perform each step. These stages and

steps should follow a logical process, so the points of entry should be defined based on meeting

clearly defined expectations. Platts (1994) also notes that a methodology should provide project

management characteristics such as the resourcing needs and constraints with agreed timescales

for completion.

100

Table 5.2 Platts (1994) characteristics of successful strategy formulation methodologies Procedure Participation Project management Point of entry

Well defined stages of: Gathering information; Analysing information; Identifying improvements; Simple tools and techniques; Written record

Individual and group to achieve: Enthusiasm; Understanding; Commitment Workshop style to: Agree objectives; Identify problems; Develop improvements; Catalyse involvement; Decision making forum

Adequate resourcing, identify: Managing group; Supporting group; Operating group Agreed timescale

Clearly defined expectations; Understanding and agreement of managing group Commitment from managing and operating groups

Source: Platts (1994)

Existing SCM methodologies focus heavily on the procedure and neglect participation, project

management and point of entry characteristics. This observation was also made by Benton (2009)

who reviewed methodologies and frameworks for selecting supply chain architecture.

Methodologies such as Naim et al., (2002) and Bolstorff and Rosenbaum (2003) suggested a range

of tools and techniques (e.g. process mapping, cause and effect diagrams) for specific steps,

described how individuals or groups achieve each step and provided some project management

considerations. Methodologies such as Blackhurst et al., (2005) and Agarwal et al., (2002) are

limited to a particular tool (e.g. probability applied trans-nets; analytic network process based

models) and do not attempt to suggest project management needs and points of entry.

The characteristics of procedure, participation and point of entry are also relevant in a

methodology for creating a conceptual model. Significant research activity and testing with actual

users would be required in order to incorporate project management characteristics, so this is

omitted as a requirement for the purposes of this thesis. A procedure will define each of the

stages necessary to define the problem and create a conceptual model of that problem, using

appropriate tools or techniques. It should make explicit how the modeller and the client interact

to complete each step of the defined procedure. Additionally, clearly define the expectations

from each step and how each step should be entered after the completion of a previous step.

5.3 Requirements for conceptual modelling of supply chain problems

This section identifies the specific requirements for conceptual modelling of supply chain

problems. The role of the methodology is to capture the complexity and detail of supply chain

problems for a given objective within the supply setting. The implications of this is to define what

complexity and detail needs in the context of SCM, the range of objectives to measure

performance and how the interconnections between them and the supply setting can be

101

determined. The characteristics underlying theses requirements are identified from discussions in

the general supply chain literature and particularly in simulation contributions.

5.3.1 Handle the complexity and detail of supply chain improvements

The methodology needs to be able to handle the complexity and detail of supply chain problems.

This is important when describing an improvement within the supply setting of the problem.

Firstly, complexity is described followed by the detail of supply chain improvements.

5.3.1.1 Complexity of supply chain improvements

A previous discussion argued that supply chains are inherently complex and dynamic systems (C.f.

section 2.2). A review of the literature in general for SCM and, specifically, for simulation

applications, demonstrates that there are a number of discussions that describe the complexity of

a supply chain as a system. These characteristics are shown in table 5.3 along with the authors

that have described complexity for SCM applications and secondly specifically in the simulation

literature.

On the whole definitions or discussions of complexity in a SCM context capture the complexity of

multiple firms, multiple business activities, and the coordination of those activities across business

functions and actors in the supply chain. Beamon (1998) describes a definition for supply chain

complexity suggesting it arises from the number of echelons in a chain and the number of

facilities in each echelon. This is supported by Cooper et al., (1997) who distinguish between the

horizontal length and vertical height of a supply chain. Both these definitions describe the size of

the supply chain structure but do not consider the linkages between supply chain actors and

business processes. Harland (1996; 1997) does offer a definition for the different types of

linkages in the supply chain which refers to the integration of supply activities within firms, in

dyadic relationships, in chains of firms and in inter-organizational networks. Common to all these

levels is the flow of supply and the activities and decisions associated to that flow.

The supply chain business processes have also been described in the literature, most notably in

supply chain process reference models (e.g. Supply Chain Council SCOR model, 2008; Global

Supply Chain Forum framework presented in Croxton et al., 2001). These include processes for

planning, executing (i.e. source, make, deliver and return) and governing a supply chain. For

instance, SCOR defines five different process types: source, make, deliver and return for the

information flow and physical flow and plan to co-ordinate the other four (SCOR, 2008; Persson

and Araldi, 2009).

102

The SCM2 will need to be able to describe a complex supply problem and formulate the boundary

of the model in its supply setting which will include:

Size – number of tiers of actors in a supply chain (horizontal length) and number of

suppliers and customers within each tier (vertical height)

Business process types – describe the range of supply chain planning, execute (e.g.

source, make, deliver and return) and govern process types

Linkages between actors and business processes – describe the linkages between actors

and business processes

103

Table 5.3 Identification of the complexity of a supply problem

Characteristic Property

Support in the general SCM literature

Support in the SCM simulation literature

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

Horizontal complexity length - number of tiers X X X X X X X X X X X

Vertical complexity number of suppliers and customers within each tier

X X X X X X X X X X

Spatial complexity

number of operating locations or degree of dispersion among members within the system

X

Edges connecting the nodes

Number of edges connecting nodes

X X

intangible measure of complexity

level of coupling between firms in the supply network as evidenced in the closeness of working relationship

X

Levels of supply

Supply within the firm boundary; supply in a dyadic relationship; supply in a inter-organizational chain; supply in an inter-organizational network

X X X

supply chain structure

convergent (assembly); divergent (arborescent); conjoined; general (network)

X

Process links among supply chain partners

managed business process links; monitored business process links; not managed business process links; non-member business links

X X

Types of supply chain partnership

Primary; secondary X

supply chain flows Information flows; product flow

X

Business functions Logistics; marketing & sales; finance; R&D; production; & purchasing

X X X X

Supply chain business process types

Customer relationship management; customer service management; demand management; order fulfillment; manufacturing flow management; procurement; product development and commercialization; returns

X X X X X X X X X X

Uncertainty N/A X

technological intricacy N/A X

organizational systems N/A X

Dynamic complexity Dynamic; static X

Sources: (1) Harland et al. (1999); (2) Cooper et al. (1997); (3) Lambert, Cooper and Pagh, (1998); (4) Milgate (2001); (5) Choi and Hong (2002); (6) Webster (2002); (7) Supply Chain Council (2008); (8) Value Chain Group ( 2008); (9) Holweg and Helo (2008); (10) Vlajic, van der Vorst and Hendrix (2008); (11) Weaver, Love, and Albores. (2008); (12) Stewart (1997); (13) Beamon (1998); (14) Beamon (1999); (15) Beamon and Chen (2001); (16) Min and Zhou (2002); (17) Gardner and Cooper (2003); (18) Reiner and Trcka, 2004; (19) Tang et al (2004); (20) Weaver, Love, and Albores (2007)

5.3.1.2 Detail of a supply chain improvement

A supply chain improvement can also be described by the level of detail required to implement

the improvements within its supply setting. Generally in the simulation literature, a definition for

‘detail’ is rarely attempted (Brooks and Tobias, 1997) but discussions do exist in general, most

notably in supply chain process reference models which describe supply chain business processes.

104

Interestingly, the advent of the SCOR model has led to a number of simulation applications using

the reference model to evaluate supply chain problems using simulation and develop simulation

tools specific to the SCM domain (e.g. Van der Zee and Van der Vorst, 2005; Albores et al., 2006;

Persson and Araldi, 2009). These discussions of detail of supply chain improvements are shown in

table 5.4.

Table 5.4 Identification of the detail of supply chain improvements

Property Sub-properties

Supported in the general SCM literature

Support in SCM simulation literature

1 2 3 4 5 6 7 8 9 10 11 12 13 14

Level of aggregation

Impact of customers’ variability on internal operations; general product and customer categories; interactions with customer

X

Supply network decomposition

Level 0 supply network architecture

X

Process decomposition and detail

level 1 strategic processes; level 2 tactical processes element; level 3 operational processes or task; level 4 activities; level 5 actions

X X X X X X X X

decision making levels

Strategic; tactical; operational X X X X X X X X

Sources: (1) Lampel and Mintzberg (1996); (2) Cooper et al. (1997); (3) Stewart (1997); (4) Supply Chain Council (2008); (5) Value Chain Group (2008); (6) Beamon and Chen (2001); (7) Van Landeghem and Persoons (2001); (8) Kleinjnen (2005); (9) Barnett and Miller (2000); (10) van der Vorst et al. (2000); (11) Gardner and Cooper (2003); (12) Tang et al (2004); (13) Kleinjnen (2005); (14) Weaver, Love, and Albores (2008)

Brookes and Tobias (1997) suggest, when applied to a model, the level (or amount) of detail

usually means an assessment of the extent to which the observable system elements and the

assumed system relationships are included in the model. A model is said to be detailed if it

contains most of the elements and interactions thought to exist in the supply system being

modelled. There are two different alternative views that are common in the literature, one is of

process decomposition and the other includes different decision-making levels. The different

decision-making levels do not necessarily easily transcribe into the elements that constitute a

supply system but this is clearly possible when decomposing business processes.

The detail of a supply chain problem can be described using the different levels of process

decomposition. SCOR describes the system elements in terms of business processes at different

levels of detail. Although it does not attempt to describe a supply chain structure, it is used to

describe a supply problem from an organisation perspective connected by business processes

across a supply chain. This is unique to a supply chain problem because it captures the complexity

of the actors, business processes and linkages that were previously described.

105

The SCM2 will need to be able to describe the detail of the components in the scope of the model.

SCOR can be used to describe the different level of process decomposition (Supply Chain Council,

2008). However, Weaver et al., (2008) notes that SCOR does not attempt to describe the

configuration of actors in the structure of a supply chain. This is an important consideration when

evaluating supply chain problems so this level is added to those offered by SCOR:

Level 0: Supply network composition - Structure of the supply chain (e.g. actors)

Level 1: Business process types – Describes the role an actor plays in a supply chain

Level 2: Process categories – Describes an organisations operation strategy through the

configuration they choose for the supply chain

Level 3: Process elements – Describes how an organisation ‘fine-tunes’ its operations

strategy

Level 4: Implementation level – Describes the activities and actions required to

implement specific supply-chain management practices that are unique to an

organisation

5.3.2 Address a range of supply chain objectives

A supply problem is not only described by its complexity and detail but by how it will be

measured. These performance measures are determined by the type of performance attribute

and the detail necessary to evaluate a problem (Weaver et al., 2007). A review of current

descriptions of supply chain performance measures by Shepherd and Gunter (2006) argued there

have been relatively few attempts to systematically collate measures for evaluating the

performance of supply chains. They identified the following groups of discussions:

Whether they are qualitative or quantitative (Beamon, 1999; Chan and Qi, 2003)

What they measure: cost and non-cost (Gunasekaran et al., 2001); quality, cost, delivery

and flexibility (Schonsleben, 2004); cost, quality, resource utilization, flexibility, visibility,

trust and innovativeness (Chan and Qi, 2003); resources, outputs and flexibility (Beamon,

1999); supply chain collaboration efficiency; coordination efficiency and configuration

(Hieber, 2002); and, input, output and composite measures (Chan and Qi, 2003)

Their strategic, operational, or tactical focus (Gunasekaran et al., 2001)

The process in the supply chain they relate to (e.g. Chan and Qi, 2003; Huang et al., 2004;

Li et al., 2005b; Lockamy and McCormack, 2004; Stephens, 2001)

The supply chain management literature particularly, simulation related, focus upon a single or a

small number of performance measures necessary to evaluate a supply problem. Beamon (1999)

suggested a comprehensive performance measurement system should place emphasis on three

106

separate types of performance measures: resource measures (generally cost), flexibility measures

(generally customer responsiveness), and output measures (how well the system reacts to

uncertainty). The Supply Chain Council SCOR model v.9 (SCC, 2008) have described a 166 page

detailed document which cover Beamon’s (1998) categories, resource measures (i.e.

cost/expenses, assets/utilisation); flexibility (i.e. the same) and output (i.e. responsiveness,

reliability) which are further broken down into three levels of decomposition and link to business

practices. They also cover the categories described above, identified by Shepherd and Gunter

(2006).

Performance measures are deployed within each business unit and internal business process

(Bititci, Mendibil, Martinez and Albores, 2005). However, it is important to note that some

measures consider the overall supply chain (e.g. total supply cost of all actors, Beamon, 1998) but

there is relatively little discussion on pan-supply chain measures. For instance, Stone and Love

(2007); have suggested the need for further research into a performance metric framework that

includes measures for the impact of overall supply chain performance. The SCM2 will need to be

able to describe the range of supply chain performance attributes at the required level of detail

both within the business process, business unit and across the whole supply chain.

5.3.3 Identify interconnections with the supply setting

The model boundary is formulated by identifying the interconnections between the components

that describe the improvement and objective. This is the considerable challenge for conceptual

modelling and is one of the aims in the outline design chapter. A method that could identify the

critical and necessary links between the improvement and objective is at the heart of the

methodology.

5.4 Chapter summary

The chapter has considered three aims and their associated requirements that should be

incorporated into a methodology for simulation conceptual modelling of SCM applications. These

aims and requirements are shown in table 5.5.

Table 5.5 Aims and requirements for the SCM2

Aim Requirement

1 Meet the requirements for an effective conceptual model Keep the model as simple as possible; Build valid and credible models

2 Meet the requirements of good methodologies Provide a procedure; Note who should participate in each step; Embed points of entry

3 Meet the requirements of the requirements for conceptual modelling of supply chain problems

Handle the complexity and detail of supply chain problems; Address a range of supply chain objectives; Identify interconnections in the model and within the supply setting

107

The first aim of the methodology to be developed is to meet the requirements for an effective

conceptual model. There are two key requirements identified. One is a fundamental need to

keep the model as simple as possible and the other is to build valid and credible models. To build

a simple model for the purpose at hand was shown to have wide acceptance and importance

placed within the simulation community. Similarly a conceptual model must be an ‘accurate’

description of the computer model to be developed from both the client’s and modeller’s

perspective.

The second aim is to meet the requirements of a ‘good’ methodology. Three requirements were

identified which included the need to provide a procedure, note who should participate in each

step and points of entry need to be embedded. It was identified that a structured procedure for

creating a conceptual model of SCM applications is at the heart of this thesis, participation and

points of entry need to be included in the procedure.

The final aim is to meet the requirements of what constitutes a supply chain problem. Three

requirements were identified which include being able to handle the complexity and detail of

supply chain improvements; address the range of supply chain objectives and identify the

interconnections in the model and within the supply setting.

108

Chapter 6 Outline design for the SCM2 (Stage III)

The outline design contributes to the development of the SCM2 (stage III of the methodological

programme) and addresses one part of research objective two (to develop a methodology for

creating a simulation conceptual model for SCM applications). It builds upon the previous

forming of the required specification (stage II presented in chapter 5) and existing conceptual

modelling practice (stage I presented in chapter 4) in order to present an outline design for the

SCM2.

The core proposition argued in this chapter is that a methodology provides a guide that can be

followed by the participants, to create an effective conceptual model, with the aid of a Supply

Chain Operations process Reference model (SCOR). This encapsulates the primary contribution to

knowledge presented in this thesis. This is developed by considering the key design issues for

addressing the requirements that the methodology needs to meet (presented in chapter five).

This includes:

Design issues for developing a ‘good’ methodology (section 6.1) – Discusses a general

guide for conceptual modelling (section 6.1.1), whom the participants are and how they

are involved in the process of conceptual modelling (section 6.1.2) and the points of entry

(section 6.1.3).

Design issues for developing an ‘effective’ conceptual model (section 6.2) – Discusses

ideas for incorporating existing simplification advice and methods into the methodology

(section 6.2.1) and how a methodology can aid in the documentation and validation of a

conceptual model (section 6.2.2).

Design issues for the domain specific needs for creating a conceptual model (section 6.3)

– Discusses the importance and role of domain knowledge in the creation of a conceptual

model.

Using SCOR for conceptual modelling (section 6.4) – Discusses the opportunity of using

SCOR as one source of domain knowledge to enable a more efficient and focused process.

The aim of the discussions is to synthesise a set of key concepts that can be incorporated into the

design of the methodology (section 6.5). Each of the key concepts is linked to a general process

for conceptual modelling so that the specific phases for a conceptual modelling methodology that

addresses the needs of the SCM domain can be proposed. The chapter concludes with an outline

design of the methodology to be further refined through application in chapter seven.

109

6.1 Design issues for developing a ‘good’ methodology

This section discusses the design issues for developing a ‘good’ conceptual modelling

methodology for SCM applications. Firstly, a small number of contributions that provide a guide

for conceptual modelling are reviewed to identify some general stages (section 6.1.1). Secondly,

the different roles participants play in the context of conceptual modelling are identified (section

6.1.2) followed by the points of entry (section 6.1.3).

6.1.1 General guide for conceptual modelling

The process of conceptual modelling must address ‘how’ a modeller could create a conceptual

model. The approaches discussed in chapter four do provide some useful guidance on the general

stages for conceptual modelling but have two distinct weaknesses. This includes that they do not

necessarily answer the question of ‘how’ a conceptual model should be created (Robinson, 2004a;

2004b) and are not described in much detail.

Robinson (2004a) offers the most detailed set of stages supplemented within an outline of some

guiding principles for each stage. These general stages are listed in table 6.1 in contrast to the

stages identified in earlier contributions by Shannon (1975), Robinson and Bhatia (1995) and Pace

(1999; 2000a; 2000b). The table includes some comments on the purpose and applicability of

each stage in the context of conceptual modelling for SCM applications.

110

Table 6.1 Proposed stages for conceptual modelling in general suggested in the literature

Author Purpose and applicability in the context for

SCM applications

Co

nce

ptu

al m

od

elli

ng

stag

e

Shannon (1975) Robinson and Bhatia (1995)

Pace (1999; 2000a; 2000b)

Robinson (2004a)

Identifying the problem

Collect authoritative information on the problem domain

Developing an understanding of the problem situation

Gain sufficient understanding of the real world problem from the perspective of the client (e.g. supply chain improvement and supply setting)

Specification of the model purpose

Set the objectives

Determine the modelling objectives

Define the objectives to evaluate each supply chain improvement

Define the experimental factors and reports

Design the conceptual model: inputs and outputs

Robinson (2008a; 2008b) provides a definition of the experimental factors and reports which can be contextualised for the purpose of modelling SCM applications: The model must accept the experimental factors determined from the modelling objectives and general project objectives (i.e. supply chain improvement). Also, provide the responses that determine the achievement of, or reason for failure of the defined objectives (i.e. impact of the improvement on supply chain performance measures) (Robinson, 2008a; 2008b).

Specification of the model component’s

Determine the scope and level of the model

Identify entities and processes that need to be represented

Design the conceptual model: the model content

Determining the boundary of the model and level of detail required to represent the actual practices to be included in the model. The model components and interconnections can then be determined from a description of what should be included at the required level of detail.

Specification of the parameters and variables associated with the components

Identify simulation elements

Specification of the relationships between the components, parameters and variables

Identify relationships between simulation elements

Collect and analyse data

Not within the scope of conceptual modelling Provide a project specification

Table 6.1 demonstrates that there are some differences between the stages described by

Robinson (2004a) and the contributions published before it. Two possible reasons for this include

that the earlier work has a narrower focus upon what constitutes a conceptual model and are

weighted towards the modeller’s perspective on the process. For instance, the earlier work

concentrates upon the design of the ‘model content’, while Robinson (2004a) also places

attention on defining the problem and designing the experimental factors and reports. Even

comparing Robinson and Bhatia (1995) and Robinson (2004a), later framework demonstrates how

Robinson shifted from recognising the ‘problem definition’ stage in a simulation project to what is

now widely known as ‘conceptual modelling’.

All the contributions demonstrate that the heart of conceptual modelling is determining the

content of the model (i.e. scope and detail). Shannon (1975) and Pace (1999; 2000a; 2000b)

considered this from the modeller’s perspective (i.e. description of the model components and

111

relationships between them). This assumes that the necessary scope and detail is determined in

the description but this does not address ‘how’. The significance of Robinson’s (2004a) work is

upon the analysis that needs to be undertaken prior to describing the model components and

their relationships, which has received insufficient discussion in the literature. There are a

number of principles that have been discussed by Robinson (2004b, pg. 84) when designing the

model content:

The starting point when designing the model content is to recognise that the ‘model must

be able to accept the experimental factors and to provide the required responses’

Scope of the model ‘must provide a sufficient link between the experimental factors and

responses’. The meaning of significant being defined by the ‘level of model accuracy

required’.

Level of detail ‘represents the components defined within the scope and their

interconnections with other components of the model with sufficient accuracy’

Both scope and detail are considered in light of the ‘impact upon the models responses’

The principles identified have implications for the development of the procedure to be designed

in this thesis. This includes how a problem should be identified; the improvement and objective

defined and from these descriptions, identify sufficient and critical links between the model

components and those in the supply setting. The latter places emphasis on the formulation of the

model boundary using a guide to follow some predetermined decision rules.

6.1.2 Role of participants in the process of conceptual modelling

Ormerod (2001) provides a description of the different groups and the role that each play in a

simulation project. This includes the doers (the interveners such as policy makers), done for

clients, with project team members, done to those interviewed about the real world system and

done without members of the organisation and society who are not involved in the project, but

are affected by it (Ormerod, 2001).

In the context of the conceptual modelling stage of a simulation project, three of Ormerod’s

(2001) roles are of critical importance. Firstly, the ‘modeller’ is responsible for creating the

conceptual model; secondly, the ‘client’ is the problem owner and recipient of the conceptual

model; finally, the subject matter experts ‘SMEs’ are consulted to provide the domain knowledge

necessary to understand the supply system and to design the model content.

A methodology for conceptual modelling would need to aid a modeller to create the conceptual

model (for the benefit of the client) from the domain knowledge provided from subject matter

112

experts. Pritsker (1995) argues that the client and subject matter experts should be thoroughly

involved in a simulation project. This view is also is supported by Banks et al., (2005) who add that

such involvement increases the confidence and application of the model by its eventual user, in

particular, greater ‘confidence’ can be placed in the ‘credibility’ of the model representing the real

world problem to a desired level of model accuracy.

Conceptual modelling requires a set of skills and experience to both create a conceptual model

and to facilitate interactions between the different participants involved in the process. These

experiences and skills are learnt generally through training and education but more importantly

practice and mentoring (Carson, 2004). A gap exists between the skills and experience held by the

modeller and the domain knowledge held by SMEs. The methodology, to some extent, can bridge

this gap by providing a detailed procedure and identify ways to incorporate existing domain

knowledge from published sources (explored in more detail in section 6.4).

6.1.3 Points of entry in the methodology

The methodology is entered when a client has a supply problem to be evaluated using a

simulation approach. The description of the problem is extracted from the client, who may have

undergone a supply chain redesign initiative (e.g. Bolstroff and Rosenbaum, 2003), to identify

improvements that could bring about a desired change in the supply system. Robinson (2004a)

notes that the accuracy of this description may be dubious, so the first phase of the methodology

will need to acquire a sound understanding of the cause and effect relationships between the

improvement and objectives within the supply setting.

Robinson (2004a) also suggests that if the client has a poor grasp of a problem a number of more

formal problem structuring methods might prove useful (e.g. soft systems methodology,

Checkland, 1981; cognitive mapping, Eden and Ackermann, 2001 and casual loop diagrams,

Sterman, 2000). There have also been some more specific approaches suggested that have used

the methods listed in the context of simulation (e.g. Balci and Nance, 1985 and Lehaney and Paul,

1996).

The process of conceptual modelling is iterative (Robinson, 2004a). The reason for this is that the

process itself is one of learning and refinement. Section 6.2.2 discusses incorporating validation

checks within the methodology to ensure that a phase has been completed successfully before

proceeding. It also discusses the need for a draft description of the conceptual model to be

created so that it can be validated in full. This will enable the participants to re-enter a specific

113

phase in the methodology if any adjustments are required because of any new knowledge

identified during the process.

6.2 Design issues for creating an ‘effective’ conceptual model

This section discusses the design issues for creating an ‘effective’ conceptual model. The first set

of issues concern how the methodology can address the principle ‘keep the model as simple as

possible’ by incorporating the advice and methods on model simplification identified in chapter

four where possible (section 6.2.1). The other set of issues further develops the argument that a

methodology should aid in the creation of a conceptual model that is both valid and credible

(section 6.2.2).

6.2.1 Keep the model as ‘simple’ as possible

A central aim of the methodology is the ‘keep the model as simple as possible’ in particular by

choosing the most appropriate complexity and level of detail. A host of advice and methods for

simplifying a model was identified in chapter four, which could be incorporated into the

methodology. Each of the advice and methods on model simplifications is listed in table 6.2

along with some ideas for how they can be incorporated into the methodology.

114

Table 6.2 Incorporating model simplification advice and methods into a methodology Advice on model simplification/method

(From table 4.2) Ideas for incorporation into the methodology

Modelling process: start simple then add complexity and detail

The process can be initiated with a description of the improvement, objectives and general supply setting. The interconnections between the components that represent an improvement and provide the data sources for an objective are ‘core’ components. The model boundary can be determined by considering the interconnections within the supply setting based upon some decision rules.

Make variables into constants

The core components that have been identified have interconnections between them. Interconnections can be simplified (i.e. treated as a fixed value) if the source component does not impact upon model behaviour. A fixed value indicates the model boundary as no further interconnections need to be considered.

Aggregate variables/group components with certain shared characteristics

Aggregation provides a means for reducing the level of detail (Robinson, 2004a). This can be considered when specifying how the model components represent each actual practice.

Restrict/eliminate variables Variables can be eliminated if they do not have an effect on model accuracy or simplified with random variables.

Strengthen assumptions and restrictions Assumptions and restrictions are incorporated into the description of the model components. This is a key purpose when representing actual practices with the model components.

Exclude/drop unimportant components in the model

Components can be omitted if they have little effect on the accuracy of the model; it is a form of scope reduction (Robinson, 2004a). This is considered when determining the model boundary.

Use random variables to depict parts of the model

Each variable needs to be considered for inclusion in the model boundary in terms of its effect on the accuracy of the model. If it can be fixed, or treated as a simple distribution then there is no requirement to consider its interconnections with the supply setting.

Quantify relationships (connections) between variables

See ‘restrict/eliminate variables’

Limit the amount of uncertainty in the model/Reduce randomness

Simplify inputs to the model if they can be generated in a simplified form (e.g. simple distributions). This is determined when formulating the model boundary.

Assume a well-defined objective function or set of decision criteria/ include only output measures of interest (experimental frame)

Identify in the first stage the improvement and how it will impact upon the desired objective within its supply setting. This forces the modeller to explicitly consider the experimental frame.

Split models (divide larger models into smaller components)/ use more than one model

This is a way of making an individual model run faster and different parts of the model can be developed by different modellers (Robinson, 2004a). This is outside the scope of conceptual modelling.

Proper use of data Extracting the required domain knowledge is a critical consideration throughout the process of conceptual modelling.

It is clear that a methodology could incorporate, on the whole, the ideas noted in table 6.2. These

ideas can be grouped into four themes. Two focused upon describing the problem adequately

and extracting the required domain knowledge (both ideas are considered in more detail in

sections 6.4 and 6.5). A third considers how actual practice is represented by the components of

the model by incorporating assumptions and simplifications. The fourth theme sheds more light

on ideas to determine the model content.

It is previously noted that Robinson (2004a) has offered some principles for determining the

model content but no formal methods. One aspect of this is to determine the model boundary,

which in the context of SCM application would concern considering the interconnections between

‘core’ components and those that are deemed ‘critical’ in the supply setting. To implement this

principle and respect the need to keep the model as simple as possible the following need to be

considered:

115

1. ‘Core’ components to be included in the model can be identified from the improvement

and objective

2. Components that provide a source interconnection are effectively ‘candidates’ for

possible inclusion

3. Candidate components can be ‘promoted’, thus included in the model if the input

generated will affect model behaviour by significantly impacting upon the objectives of

study (and excluded if they do not affect model behaviour)

4. Included components can be considered for simplification if they can be represented as

either a fixed value or simple distribution

5. Simplified inputs represent the boundary of the model as no further inputs can be

considered

6.2.2 Creating a ‘valid’ and ‘credible’ conceptual model

In chapter 4 (c.f. sections 4.3 and 4.4) existing practices were considered in relation to

documenting and validating a conceptual model. It was argued that validation is of particular

importance in simulation modelling but there is a lack of methods, or even advice, at the

conceptual modelling stage. The methodology can also incorporate a means for documenting and

validating a conceptual model, adding considerable value to the procedure.

Table 6.3 lists the general stages for conceptual modelling as proposed by Robinson (2004a;

2004b) and describes the requirements for documenting the output from each stage and how it

could be validated. The table lists Robinson’s (2004a; 2004b) framework because it is the most

detailed and comprehensive and consults Shannon (1975) and Pace (1999; 2000a; 2000b) to

identify desired outcomes for each stage. The documentation and validation requirements are

considered for delivering each outcome in the context of evaluating supply chain problems. This

is useful as the general frameworks consulted do not explicitly state how to document the

outcomes from each stage and none have incorporated validation considerations.

116

Table 6.3 Documentation and validation requirements for the SCM2

General conceptual modelling stage

(Robinson, 2004a; 2004b)

Desired outcomes

What are the requirements for documenting the desired outcome from each stage in the context of

SCM applications?

How can it be validated?

Developing an understanding of the problem situation

Description of the problem situation from the clients perspective

Description of the objective of study

Description of how the supply system is to be improved

Description of the supply setting

Check the description of the supply problem is correct for the purpose at hand from the client’s perspective. The proceeding analysis is dependent upon this information.

Determine the modelling objectives (and how each improvement is to be represented)

Model objectives

Description of how each process is to provide data used to calculate each objective

Description of how each process is to represent each improvement

Check the description of how the objective is to be measured and how an improvement is to be represented for ‘correctness’ with SME’s.

Design the conceptual model: inputs and outputs

Experimental factors; Responses

List of model processes and source inputs that provide an interconnection

Check with SME’s that the processes and source inputs are correct for the purpose at hand.

Design the conceptual model: the model content

Model components; Relationship between components

Description of the components that represent each actual practice and how their relationships

Check with SME’s that the actual practices to be modelled are sufficient and correct (i.e. no critical omissions or unnecessary details). If these are not correct then it would not be possible to convert the actual practices into the model components and interconnections.

Description of the actual practices to be modelled and their relationships

Check how each model component and their interconnections provide a sufficient and correct link between the objectives and improvements.

Description of any assumptions or simplifications incorporated into the model components and interconnections

Check with SME’s that the assumption and simplifications incorporated into the conceptual model are correct, without significantly impacting on the probable model accuracy.

The descriptions provided by each of the stages of conceptual modelling need to be validated

during the process to improve the validity and credibility of the conceptual model. It is

particularly important to note that the process of conceptual modelling is sequential; certain

outputs are required to initiate and drive the analysis (e.g. model boundary is derived from

modelling a description of the improvement and objectives). Iteration is necessary when issues

arise regarding the ‘correctness’ of the outputs documented in each stage. Using the descriptions

provided in table 6.3 six issues can be distinguished that could invalidate a conceptual model:

1. Incorrect description of the supply problem from the perspective of the client

2. Incorrect description of the improvement and the performance measures and how they

are to be included and represented in the model

3. Incorrect information obtained from the client on the processes and interconnections to

be modelled

4. Incorrect description of actual practices to be modelled (e.g. issues that concern the

scope, such as any omissions, or unnecessary details)

117

5. Incorrect description of how each actual practice is to be modelled by the components in

the model and their interconnections (e.g. issues that concern the detail and assumptions

and simplifications incorporated into the model)

6. Insufficient links between the critical interconnections between the improvements and

the objectives of study

6.3 Design issues for the domain specific needs for creating a CM

A procedure for conceptual modelling would need to obtain information provided from sources

that are specific to a particular domain. Section 6.1.2 noted that domain knowledge is acquired

principally from consultation with SMEs. This section of the thesis firstly argues that a supply

chain process reference model is a complimentary source that could provide an opportunity to

enable a more efficient and focused SCM2 (section 6.3.1). Secondly, SCOR is identified as a

suitable process reference model from the range of alternatives (section 6.3.2) before its

usefulness is described in more detail in section 6.4.

6.3.1 Opportunities to use a process reference model for creating a CM

A process reference model represents a class of domain (Becker et al, 2003) that can be used to

accelerate the development of a model (Fettke and Loos, 2003). Table 6.4, identifies

opportunities to use a process reference model to enable a more efficient and focused conceptual

modelling process against the requirements. The main advantage offered by a process reference

model is that it provides standard language and content to describe a supply chain configuration.

Three significant opportunities exist when formulating the problem precisely; gathering

information from client sources and to focus interaction between the stakeholders in a

conceptual modelling project.

Table 6.4 Role of domain knowledge in conceptual modelling

Objective Requirement Opportunity to make the process more efficient and focused

1. Meet the requirements for an effective conceptual model

Build the most simplest model for the purpose at hand

Use domain knowledge to extract an accurate representation of the real system for the purposes at hand

Build a valid and credible model

Aid in formulating the problem precisely from the client’s perspective and focus consultations with SMEs to determine the model content (Law, 2008)

2. Meet the requirements of good methodologies

Procedure Steps and information requirements can be described using standard terms and language common to the SCM domain

Participation Procedure that suggests how the participants should be involved the process and what information is required from them.

Point of entry N/A

3. Meet the requirements for conceptual modelling for SCM applications

Supply chain improvements

Standard language and terms for describing a supply problem and the details necessary to analyse the interconnections between ‘core’ components and those in its supply setting.

Supply chain objectives

Supply chain setting

118

6.3.2 Identification of a suitable process reference model for creating a CM

Lambert et al (2005) evaluated process-orientated supply management frameworks, identifying

five supply chain management frameworks, which recognise the need to implement business

processes in the literature. These include Bowersox, Closs, and Stank (1999); Cooper, Lambert,

and Pagh (1997); Mentzer et al., (2001); Srivastava, Shervani, and Fahey (1999) and the Supply-

Chain Council (2005, note this research uses SCOR v.9, 2008) which all hold distinctive

characteristics and objectives. The Value Chain Group VCOR model could also be added to this list

which is similar in style to SCOR but seeks to describe all the processes and activities within an

organisation.

Lambert el al., (2005) note that four of the five frameworks they identified suggest

implementation of standard cross-functional business processes. However, only the Global

Supply Chain Forum (GSFC) and Supply Chain Operations Reference model (SCOR) frameworks

include business processes that could be used by management, to achieve cross-functional

integration and are described in the literature with enough detail to draw meaningful

comparisons. This also stands true for the VCOR model which, in its infancy, has little published

literature available other than on its website which is restricted to members who pay a fee.

Table 6.5 draws some comparisons between the GSFC description of supply chain business

processes and the SCC SCOR model. Becker et al., (2003) six main qualities for an effective model

is used so that the opportunities and limitation of using a process reference model can be

considered in light of conceptual modelling. The key finding is that only the SCOR model can

provide the domain knowledge necessary for conceptual modelling. This is supported by a

number of research publications that have discussed the applicability of SCOR for simulation

purposes (e.g. Barnet and Miller, 2000; Arns et al., 2002; Terzi and Cavalieri, 2002; Min and Zhou,

2002; Hermann, Lin and Pundoor, 2003; Van der Zee et al., 2005; Albores et al., 2006; Persson and

Araldi, 2009). Although argued extensively in the wider simulation literature, there is little

research that has concentrated on the opportunity to use SCOR for the purposes of conceptual

modelling.

SCOR has notable strengths over the GSFC framework in all six of the criteria for an effective

conceptual model. In particular the areas include:

Extensive development and testing with academic, corporate and software partners who

make up the membership of SCOR across the world and from different industrial contexts

Regarded as a de facto standard model for SCM

119

Applicable for use in simulation analysis (both to develop tools and describing and

evaluating supply problems)

Standard description of processes and their relationships, performance measures and

business practices

The major limitations hold for both models. Although both claim to have been developed and

evaluated with industrial and academic partners it is not clear on how systematic and rigorous the

design process was. All that can be drawn is that the Supply Chain Council has advanced the

model and revised it on eleven occasions with collaboration with academics, technology providers

and the government organisations that participate in the council’s activities. The other key lesson

that can be drawn from the analysis is that the ‘clarity’ and ‘economic efficiency’ of both models is

difficult to ascertain. It is clear that an advantage of a process reference model is to offer

standard descriptions but the question still open is ‘how these descriptions can be effectively

used for the purposes of conceptual modelling’. This question is explored in more detail in

section 6.4 using the SCC SCOR model, as it offers considerable strengths over the GSFC model

and has been shown to be applicable for simulation modelling purposes.

120

Table 6.5 Comparison of supply chain process reference models Global Supply Chain Forum process reference model

(e.g. Cooper, Lambert and Pagh, 1997) Supply-Chain Council SCOR model v.9 (2008)

Correctness Developed and evaluated with members of the supply chain forum (includes fifteen major US corporations). No extensive testing has been claimed.

Developed and tested originally with 69 voluntary member companies and now has over 1,000 corporate and academic members established in each region across the world, from different industrial contexts (e.g. manufacturers, services, distributors, and retailers). It is now in its eleventh revision (SCC, 2008).

Relevance

The aim is to ‘help with implementation, instructors with material for structuring a SCM course and researchers with a detailed framework for future research in SCM’ (Croxton et al., 2001, pg. 14). There is no evidence of the model being used for simulation purposes other than for the reasons noted in ‘economic efficiency’ (e.g. Arns et al., 2002; Min and Zhou, 2002 use the model to define SCM and Terzi and Cavalieri, 2002 do not include it in their survey of simulation in the supply chain context).

It is often regarded as a de facto standard model in SCM (Stewart, 1997) and known as a well established and well practiced model (Swafford, Ghosh and Murthy, 2006). SCOR has been considered for its applicability for simulation purposes (e.g. Barnet and Miller, 2000; Arns et al., 2002; Terzi and Cavalieri, 2002; Min and Zhou, 2002; Hermann et al., 2003; Van der Zee et al., 2005, Albores et al., 2006; Persson and Araldi, 2009).

Economic efficiency

The work has been widely cited in research publications. Its main use has been for defining SCM, teaching purposes and identifying areas for future research (e.g. Lambert et al., 1998; Lambert and Cooper, 2000).

The model allows companies to (Stewart, 1997 and Huan, Sheoran and Wang, 2004 cite SCC, 1999): evaluate their own processes effectively; compare their performance with other companies both within and outside their industry segment. Pursue specific competitive advantages, use benchmarking and best practice information to prioritize their activities, quantify the benefits of implementing change, and identify software tools best suited to their specific process requirements.

Clarity Eight key processes that make up the core of supply chain management are described at the strategic and operational levels. The sub-processes describe typical activities.

The SCC (2008) states: SCOR provides a standard description of management processes, a framework of relationships among the standard processes, standard metrics to measure process performance, management practices that produce best in class performance and standard alignment to software features and functionality.

Comparability

The paper assumes that the ‘eight key business processes run the length of the supply chain and cut across firms and functional silos within each firm’ (Croxton et al., 2001, pg. 14). The work notes that all firms should consider the eight processes but the importance of each process and specific activities will vary. Its primary focus is for describing and defining SCM.

The standard is used widely for benchmarking activities (e.g. Gilmour, 1998). Huan et al., (2004, pg. 24) analysis suggest that it has a ‘complete’ set of supply chain performance metrics, industry best practices and enabling system which can be used to perform ‘very thorough fact based analyses of all aspects of their current supply chain’.

Systematic design

Not detailed. All that is claimed is that it has been developed and evaluated with industrial collaborators (see note in ‘correctness’).

Advanced through collaboration with ‘technology suppliers and implementers, academicians and government organisations that participate in the council activities and the development and maintenance of the model’ (SCC, 2008, pg. 1.1.1).

121

6.4 Using SCOR for conceptual modelling

This section expands upon the argument that SCOR could be used as one source that can make

the process of conceptual modelling more efficient and focused. The previous section identified

SCOR as a supply chain reference model that could provide the detail on the improvements

(termed ‘best practices’), objectives (the descriptions of performance attributes and metrics) and

the supply setting (e.g. processes and relationships between them). The detail offered by SCOR

for each of these requirements is summarised in table 6.6.

Table 6.6 Domain knowledge offered by SCC SCOR model Detail offered by SCOR

List of supply chain improvements (‘best practices’)

Glossary of supply chain best practices with associated definitions and processes that implement each practice

Major best practices are described in more detail (i.e. best practice needs and suitability indicators, impact on supply chain performance attributes/metrics, key best practice success factors and additional resources)

List of objectives and metrics (‘performance attributes and metrics’)

Range of performance attributes (characteristics of the supply chain which permit it to be analysed and evaluated against other supply chains with competing strategies)

Each performance attribute can be decomposed using the hierarchy of metrics into level 1 strategic metrics, level 2 and 3 lower level calculations (generally associated with a narrower subset of processes)

Level 1 and 2 metrics are described in detail (i.e. qualitative relationship description, quantitative relationships, calculation, data collection from SCOR processes, discussion and a graphic of the associated level 2 and 3 metrics in a hierarchy tree)

Level 3 metrics are described and the data collection needs from SCOR processes are listed

Supply setting (‘Supply processes and their relationship’)

Graphics provide a visual representation of the process elements and their relationships to each other

Inputs and outputs that are germane to each process element

Following the graphics are text tables that identify: 1) the standard name for the process element, 2) the notation for the process element, 3) SCC’s ‘standard’ definition for the process element, 4) performance attributes that are associated with the process element, 5) metrics that are associated with the performance attributes, 6) best practices that are associated with the process (candidates, not necessarily an exhaustive list)

Model focuses on three environments: make-to-stock, make-to-order, and engineer-to-order

Extracted from: SCOR V.9 (2008)

The following three sub-sections demonstrate how SCOR could be used to describe and analyse

an improvement (section 6.4.1), objectives (section 6.4.2) and its supply setting (section 6.4.3).

This is achieved by considering two examples of typical supply chain problems from the literature,

extracted from five research studies that have cases that have been evaluated using simulation.

Table 6.7 lists the purpose of each study, objective and improvements. The two improvements

considered include vendor managed inventory (VMI) and collaborative, planning, forecasting and

replenishment (CPFR). These improvements have been studied for various objectives of study

(e.g. inventory reduction, improve service level and improve total supply chain cost).

122

Table 6.7 Examples of two typical supply chain problems

Contribution Disney and Towill

(2003a; 2003b) Reiner and Trcka

(2004) Sari (2008)

Southhard and Swenseth (2008)

Chang et al., (2007)

Example case in the literature

The effect of vendor management inventory (VMI) dynamics on the bullwhip effect in supply chains

Supply chain design: Problems and alternatives for a production company in the food industry: A simulation based analysis

On the benefits of CPRFR and VMI: A comparative simulation study

Evaluating VMI in non-traditional environments

A study of an augmented CPFR model for the 3C retail industry

Objective of study

Bullwhip (peak order rate to step input and order rate variance) and stock performance (system and production inventory, inventory availability)

Minimise WIP inventory, fill rate (service level) and lead-times (cycle-times)

Reduction in total supply chain cost, customer service level (fill rate)

Inventory system costs, delivery costs and stock outs

Monthly inventory turnover rate; capital turnover; out of stock rate; service level

Improvements Implement VMI between manufacturer and customer

Distribution of orders between partners, decision rules in the supply chain, layout of the supply chain

Implement collaborative planning, forecasting and replenishment, vendor managed inventory

Implement VMI between manufacturer and customer

Implement collaborative planning, forecasting and replenishment

6.4.1 Using SCOR to describe supply chain improvements

SCOR provides over 420 supply chain practices which could be selected based upon the type of

improvements that may wish to be evaluated (Weaver et al., 2007). Sixteen best practices are

described as major and are detailed with a description, impact on supply chain performance

attributes/metrics and key success factors. An example of VMI and CPFR is provided in table 6.8,

describing the SCOR process and the information that could help determine the potential impact

on supply chain performance attributes/metrics.

Table 6.8 Example of SCOR detail extracted for improvements

Improvement SCOR

processes Impact on supply chain performance attributes/metrics

Reliability Costs

VMI

P1, P2, P4, S1.1, S2.1, S3.3, ES.7, D1, D1.5, D1.6, D2.5, D2.6, D3.5, D3.6

VMI helps to assure the availability of items thereby helping to ensure better on-time delivery performance as well as greater fill rates

Inventory level decreases by up to 20% leading to lower inventory costs. The supplier gets a clear view of demand and flexibility (see above), so that they can achieve lower variable manufacturing costs

CPFR P1 (Plan Supply Chain)

Better store in stock (2% - 8%) Better customer service (2% - 8%)

Lower logistics cost (3% - 4%)

Extracted from: SCOR V.9 (2008)

Although only the major best practices are described in this level of detailed description, the

business processes have further information that could be useful. This includes a description of

the process, which performance attributes apply and the associated metrics. The description also

lists other best practices that may be implemented as part of the process selected to represent

each improvement (and performance measures).

6.4.2 Using SCOR to describe supply chain objectives

The supply chain objectives can be represented using the SCOR metrics at three levels of

decomposition. SCOR provides primary high level strategic measures that cross multiple SCOR

123

processes and lists a hierarchy of associated lower level metrics to calculate each of the higher

level metrics. The level 1 metrics do not necessarily relate to a SCOR level 1 process type (e.g.

plan, source). The metric hierarchy tress included in the SCOR model are useful to identify how a

supply chain performance attribute can be measured by a range of associated metrics at three

different levels.

The examples provided in table 6.8 demonstrated a range of metrics being used to measure the

performance of implementing VMI and CPFR improvements. Generally, these studies examined

total supply chain cost, reduction of inventory and maintaining a desired customer service level

(fill rate). Table 6.9 translates these into SCOR performance attributes and identifies the

associated level 1, 2 and 3 performance metrics. For each performance metric, SCOR provides a

definition of how the metric is to be calculated and indicates the data required to perform the

calculation and the source process.

Table 6.9 Example of extracting SCOR performance measures Performance

attribute Performance metric level

Performance metric Definition of metric calculation Data collection source

Improve supply chain cost by minimising WIP inventory

Level 1 metrics CO.1.1 Total Supply Chain Management Cost

TSCMC = Cost to Plan + Source + Make + Deliver + Return + Mitigate Supply Chain Risk

Any related level 2 process category

Level 2 metrics CO.3.69 Cost to manage in-process products (WIP)

The sum of the costs associated with managing in-process products (WIP)

EM.4 Manage in-process products (WIP)

Minimise finished goods inventory

Level 3 metric AG.3.39 Current On-hand finished goods inventories

Current on hand finished goods inventories including safety stock required to sustain current order fulfillment, assuming optimized inventory practices

EM.4 Manage in-process products (WIP)

Maintain customer service level (fill rate)

Level 3 metric RL.3.36 Fill rate The percentage of ship-from-stock orders shipped within 24 hours of order receipt.

P1.3 Balance supply chain resources with SC requirements

P4.4 Establish delivery plans

M1.3 Produce and test

D1.3 Reserve inventory and determine delivery date

D1.9 Pick product

Extracted from: SCOR V.9 (2008)

Table 6.9 shows how to calculate total supply chain costs. This would include aggregating all the

costs associated with plan, source, make, deliver, return and mitigating supply chain risk, selected

if the process type has been selected. Decomposing this level one metric includes a hierarchy of

costs associated with each type and at level three, specific calculations for activities such as

managing WIP inventory etc. The example to maintain service level had many different choices

for metrics that provided specific requirements but the fill rate metric were dominated in the

124

cases selected. In this example two planning, a ‘make’ and two ‘deliver’ decomposed processes

provide the data source to perform the metric calculation.

6.4.3 Using SCOR to determine the interconnections with the supply setting

The SCOR model provides the inputs and outputs to each decomposed business process

distinguished by manufacturing environment (i.e. make-to-stock, make-to-order and engineer-to-

order configurations). Figure 6.1 shows a sample of the detailed workflow for S1.2 (receive

product), a third level decomposed business process element that is associated with receiving

product to contract requirements. The ‘S’ depicts that it is a source process element and at level

two, the ‘S1’ indicates it is concerned with source stocked product and is specific to receiving

product, ‘S1.2’.

Figure 6.1 Example of SCOR inputs and outputs to a decomposed business process Source: SCOR V.9 (2008)

SCOR can be used to identify the interconnections between business processes using the

descriptions of inputs and their source process elements. Sections 6.4.1 and 6.4.2 showed that

SCOR can be used to identify the processes germane to a supply chain objective and improvement

at a particular level of decomposition (i.e. level of detail is predefined). These can be classed as

the ‘core’ components and their source interconnections ‘candidates’ for possible inclusion. This

provides an opportunity to evaluate each interconnection based upon some decision rules with an

aim of determining the boundary of the model.

125

6.5 Presentation of outline design

The outline design presents a synthesis of the ideas considered for each design issue discussed in

this chapter. These ideas are presented as the key concepts for incorporation into the

methodology. Each of these key concepts are identified and justified based upon the issues

identified in this chapter in section 6.5.1. Secondly, each key concept is linked to one of the

general conceptual modelling process stages before identifying specific phases that should be

included in the methodology (section 6.5.2).

6.5.1 Key concepts to be incorporated into the methodology

Ten key concepts have been synthesised from the discussion of the design issues for each of the

requirements for developing the SCM2 (outlined and described in table 6.10). Each of the key

concepts is outlined in table 6.10 with a brief description. The core idea developed in this chapter

is that SCOR can be utilised to make the process of conceptual modelling more efficient and

focused. The main role of SCOR is to provide a critical source of domain knowledge to drive the

process of conceptual modelling (key concepts 1 – 4), aid in decision-making process when

formulating the model boundary (key concepts 6 and 7) and aid in the description of the actual

practices to be represented in the model (key concept 8). The other core ideas include, how the

model boundary is formulated using some decision rules to include or exclude processes (key

concept 6) and simplify model inputs (key concept 7), representing the model content (key

concept 9) and for documenting and validating the conceptual model (key concept 10).

Key concept one states how a supply problem should be described (i.e. objective, improvement

and supply setting – see section 6.4). The objective describes the performance attributes (e.g.

cost, responsiveness, agility) that an improvement in the supply chain must achieve. An

improvement describes the way in which the client wishes to alter the existing supply system to

meet the objective, while the supply setting describes the nature of the real world in which the

improvement interconnects with each objective. This is central to the design of the conceptual

modelling process as all further steps are derived from an understanding of the supply problem

and the output of the process is validated against the objectives set.

126

Table 6.10 Key concepts to be included in the design of the SCM2

Key Concept Description

1. Supply chain problem describe the objective, improvement and supply setting

Objectives describes the performance attributes (e.g. cost, responsiveness, agility) that an improvement in the supply chain must achieve

Improvements describe the way in which the client wishes to alter the existing supply system to meet the objective

Supply setting describes the nature of the real world in which the improvement interconnects with each objective

2. SCOR SCM performance metrics can be used to identify how an objective is to be measured

SCOR provides a hierarchy of performance metrics for each supply chain performance attribute with associated detail. The detail includes a description of each metric, calculation and the process elements that provide data to perform each calculation

3. SCOR practices can be used to describe each improvement to be evaluated

SCOR provides a list of practices with associated detail. The detail includes a description of the practice, for major practices the impact that the practice should have on SCOR performance metrics and the process elements that are germane to each practice

4. Identification of the core processes that need to be modelled, their inputs generated from a source process element

The process elements associated with each objective and improvement is identified and classified as core process elements included in the model. Each process element has a list of inputs fed into the process from a source process element.

5. Process elements that have yet to be included in the model can be classed as candidates for possible inclusion

The source process element that feeds an input to each process element included in the model are considered for inclusion in the model

6. Candidate process elements are considered in turn for inclusion in the model, as they form a critical interconnection between the core processes and the real world

Candidate process elements are included in the model if the input to be generated will affect model behaviour by significantly impacting upon the objectives of study.

Those that do not can be excluded, if the client or modeller is unsure then they must be tested by prototyping using sensitivity analysis.

7. Included process elements are considered in turn to identify those that could be simplified

Process elements that feed an input that can be generated in a simplified form (e.g. fixed value, simple distribution) can be simplified. No inputs are fed into simplified process elements; therefore they indicate the boundary of the model.

Process elements that cannot be simplified, must be promoted (included in the model) and treated similarly to core process elements (thus the process repeats to identify candidates for inclusion in the model).

8. The detail that needs to be included can be identified from the actual practice for each process element included and simplified in the model

SCOR provides a list of typical practices for each process element. These can be reviewed in light of the general practices described from the client’s perspective.

9. Modelling practice should represent the complexity and detail of the actual practice to be evaluated

The actual practice should be considered in turn to identify the activities that need to be modelled to generate the desired output from the inputs identified in the simplest way without effecting model accuracy. The entities that need to be modelled are identified.

10. The conceptual model is documented and validated

The conceptual modelling report is documented from the objectives, improvement, model content, assumptions and simplifications made about the model to be developed.

The conceptual model is validated

Key concept two states that SCOR can be used to describe each objective in terms of performance

metrics, calculations and data sources necessary to perform each category (shown in section

6.4.2). Similarly for key concept three, SCOR provides a list of practices with associated detail

which includes a description of the practice and the process element that are germane to each

practice (shown in section 6.4.1). The major best practices (e.g. VMI, CPFR, cross-docking) used

by SCOR practitioners are listed in more detail. This is useful as this also suggests the impact that

each practice should have on related SCOR performance metrics. This can be used to verify that

each improvement will have an impact on desired performance so to focus the study on those

improvements that could address the objective.

127

The importance of key concepts two and three is that the process elements, which are germane

to each improvement and objective, have been identified. These process elements can be

classified as ‘core’ process elements that are to be included in the model (key concept four). The

SCOR process elements have a set of inputs that are fed from a source process element. These

inputs can be considered for inclusion in the model; they are, effectively, candidates that need to

be included or excluded based upon some rules (key concept five).

Each candidate process element can be considered in turn for inclusion in the model as they form

a critical interconnection between the core processes and the real world (key concept six).

Candidate process elements are included in the model if the input to be generated will affect

model behaviour by significantly impacting upon the objectives of study (discussed in section

6.2.1). Those that do not can be excluded. An alternative option is added to the criteria to

include those process elements in which the modeller is ‘unsure’. This provides a list of those to

discuss and confirm in greater detail with the client. Ultimately, the process elements that could

not be determined should be ‘tested’ by using a prototyping method.

The boundary of the model can be determined by identifying those ‘included’ process elements

that generate an input to be fed into the model which can be simplified (key concept seven). The

rule, which determines whether the input can be simplified, is determined by asking: can the

element be generated in a simplified form (e.g. a fixed value, simple distribution)? This indicates

the boundary of the model because no further inputs are needed to generate the input. The

process elements that cannot be simplified must be ‘promoted’ (included in the model) and

treated similarly to ‘core’ process elements. The process is repeated until all candidate process

elements have been identified and considered for inclusion. The point when no further

candidates can be considered indicates that the model boundary has been reached and all

process elements that should be included have been (both core and promoted process elements).

The detail of the model can be identified from the actual practice for each process element

included and simplified in the model (key concept eight). The SCOR model practices can be used

as examples of typical practices that have been used for each process in a supply chain context.

This enables the modeller to have an indication of the types of practices that could be modelled

prior to obtaining, from the client, the actual practice from the client’s perspective.

The conceptual model needs to represent the complexity and detail of the actual practice in terms

of how it will be modelled (key concept nine). The modeller needs to consider each actual

128

practice to identify the activities and events that would need to be modelled, to generate the

desired output from the inputs identified. Although the inputs have previously been identified

the process has also identified the outputs as they feed into a ‘core’ or ‘promoted’ process

element. The modeller is concerned with identifying the simplest way to model the activities and

actions without affecting model accuracy. To do this the entities that need to be modelled are

identified.

The final key concept concerns documenting and validating the model to be developed (discussed

in section 6.2.2). The output of the process is a description of the computer model to be

developed (e.g. objectives, improvement, model content, assumptions and simplifications).

Validation checks should be incorporated into the methodology phases where appropriate and

provides a final hypothesis validation test.

6.5.2 Linking key concepts to phases in the SCM2

Seven phases are required to incorporate the ten key concepts into a procedure for the SCM2.

These phases have been identified by linking each key concept to the general stages in a

conceptual modelling process that were identified in section 6.1.1 (this is shown in table 6.11).

Each of these phases is justified in this section.

Table 6.11 Linking key concepts, conceptual modelling process with phases in the SCM2

Key concept Conceptual modelling

process Phase in SCM2

1. Supply chain problem describe the objective, improvement and supply setting

Problem structuring and setting objectives

Phase 1: Describe the supply chain problem from the clients perspective

2. SCOR SCM performance metrics can be used to identify how an objective is to be measured

Defining the experimental factors and reports

Phase 2: Determine how each objective is to be measured

3. SCOR practices can be used to describe each improvement to be evaluated

Phase 3: Determine how each improvement is to be represented

4. Identification of the core processes that need to be modelled, their inputs generated from a source process element

Determining the model

content (i.e. complexity

and detail)

Phase 4: Determine the model inputs and source process elements that interconnect within the model and the immediate supply setting

5. Process elements that have yet to be included in the model can be classed as candidates for possible inclusion

6. Candidate process elements are considered in turn for inclusion in the model, as they form a critical interconnection between the core processes and the real world

Phase 5: Formulate the model boundary

7. Included process elements are considered in turn to identify those that could be simplified

8. The detail that needs to be included can be identified from the actual practice for each process element included and simplified in the model Phase 6: Design the level of detail necessary

to implement the model 9. Modelling practice should represent the essential complexity and detail of the actual practice to be evaluated

10. The conceptual model is document and validated Provide a project specification

Phase 7: Document and validate the conceptual model

129

The process of conceptual modelling is initiated by identifying the supply problem from the

client’s perspective (key concept one and phase one). The experimental factors correspond to

how the improvement is to bring about a change in the supply system (phase two) and the

reports correspond to how each objective is to be measured (phase three). These phases are

separated as they require different checks to ensure that the descriptions provided are ‘correct’.

This is important because the descriptions provided drive the analysis of the model content so

must comprehensively represent the objective and improvement so that the interconnections

with the supply setting can be determined.

Phase one – six correspond to determining the model content (i.e. complexity and detail). This is

because they first identify interconnections between core components and the supply setting and

offer some rules to decide upon whether they should be included or not. Firstly, SCOR is used to

extract the domain knowledge necessary to identify the inputs to each ‘core’ process element and

how it interconnects within the model and the immediate supply setting (phase four). The

purpose of this stage is to identify ‘candidate’ process elements that have yet to be considered for

inclusion. Phase five builds upon the descriptions obtained in phase four so to formulate the

model boundary. Each of the inputs is fed from a candidate process element that could be

included as they may form a critical interconnection between the processes included in the model

and with the real world. Here, candidate improvement options are simplified, promoted, tested,

or excluded, based on the two rules defined in section 6.2.1.

Phase six designs the level of detail necessary to implement the processes and simplified inputs

identified in the model boundary. The level of detail is determined by identifying the actual

practice for each process included and simplified in the model. This is a form of aggregation as

the actual practice may occur in more than one process. From this analysis, the modeller decides

on the modelling practice to represent the essential complexity and detail of the actual practice to

be evaluated.

Phase seven documents and validates the conceptual model. This phase cannot be seen as the

end phase but a phase that refines the model throughout each of the phases. The output of

phase seven is a validated description of the computer model to be developed agreed by both the

client and the modeller.

130

6.6 Chapter summary

The chapter has considered the design issues for each of the requirements for the SCM2. The

discussion has led to a range of ideas being synthesised into a set of ten key concepts for inclusion

in the procedure. Each of the key concepts have been aligned to a general process of conceptual

modelling, so to deduce a set of phases that are specific for conceptual modelling in the domain

of SCM. An outline of phases in the methodology is shown in table 6.12 along the inputs that

require information and outputs that provide information from the methodology.

Table 6.12 Outline of the methodology: Phases, inputs and outputs Inputs to the SCM2 Phases in the (SCM)2 Outputs from the (SCM)2

From the client:

Supply chain objective(s)

Supply chain improvement(s)

Supply setting

Phase 1: Describe the supply chain problem from the clients perspective

Statement of supply problem

Use SCOR to identify the following from the description of the supply chain objective(s):

Supply chain strategic and diagnostic metrics

Supply chain metric calculation

Data collection requirements from each process element

Phase 2: Determine how each objective is to be measured

Statement of how each process is to provide the data used to calculate each objective

Use SCOR to identify the following from the description of the supply chain improvement(s):

Level of process detail for each improvement (includes process element that represents each improvement)

Phase 3: Determine how each improvement is to be represented

Statement of how each process is to represent each improvement (i.e. list of processes germane to each improvement)

Use SCOR to identify the following from the process elements identified in phase two and three:

Inputs fed to each process element included in the model

Source process elements can be discriminated based upon whether they exist in the model or not

Phase 4: Determine the model inputs and source process elements that interconnect within the model and the immediate supply setting

List of model inputs and candidate process elements

The modeller with input from the client considers each ‘candidate’ process element in turn against each rule

Phase 5: Formulate the model boundary

Statement of the model boundary (includes a list of process elements promoted, simplified, excluded and those that require testing)

The modeller uses SCOR and client sources to identify and describe actual practice and represent this into modelling practice

Phase 6: Design the level of detail necessary to implement the model

Statement of actual practice and how it will be represented in the model

Inputs from phases one - six Phase 7: Document and validate the conceptual model

A valid description of the computer model to be developed

Table 6.12 represents the procedure as a logical and sequential set of phases to be completed.

However, iteration will be necessary in particular when a validation check has not been satisfied

and when determining the model boundary (between phases five and four).

A benefit offered by the methodology, is that SCOR has been incorporated into the design to

enable a more efficient and focused process (e.g. provide information necessary to drive the

analysis, useful aid when consulting SMEs). Additionally, validation checks will be necessary when

131

describing the supply problem, improvement, objective, model boundary, and description of how

the actual practices are to be represented in the computer model. This will be the result of

learning during the process of conceptual modelling, leading to adjustment when necessary.

The following chapter (chapter seven) details and refines the outline methodology defined in this

chapter so that it is aligned to meet the specification of requirements. The development of the

methodology is founded upon a strong conceptual base and an evaluation of how each

requirement can be considered in the design of the methodology.

132

Chapter 7 Detailed design for SCM2 (Stage IV)

This chapter implements stage IV of the research methodological programme by refining and

detailing the methodology with two supply chain applications. It is the final stage to address the

second objective of the research to ‘develop a methodology for simulation conceptual modelling

in the context of SCM applications’. The detailed methodology is aligned with the required

specification, presented in chapter five, to demonstrate that it meets the requirements. This is

completed before the SCM2 is preliminarily validated in chapter eight.

The chapter is structured to:

Overview of the SCM2 (described in section 7.1 and represented in figure 7.1) - Present an

overview of the phases and steps to follow as laid down in the SCM2

Presentation of the development cases (described in section 7.2) - Present the supply

chain application cases to detail and refine the SCM2 with rationale for their selection

Application of the development cases to refine and detail the SCM2 (each phase is

justified in section 7.3) - Discuss how each phase in the SCM2 was detailed and refined

with illustration of the decisions made in the design using the two supply chain

applications

Implementing the SCM2 using a spreadsheet application (discussed in section 7.4) -

Discuss how the SCM2 can be implemented using a spreadsheet application to provide

templates and automate a number of the steps

Alignment of detailed design of SCM2 against specification (discussed in section 7.5) -

Demonstrate that the detailed and refined design of the SCM2 methodology meets the

specification of requirements identified in chapter five

7.1 Overview of the SCM2

The aim of the methodology is to provide a prescribed procedure to aid the users to create a

simulation conceptual model for SCM applications. The output from the methodology is a

documented and validated description of the computer model to be developed (the conceptual

model). The methodology includes seven phases, associated detailed steps, who participates in

each step and the information needs that incorporate each of the key concepts described in

chapter six. It has been developed to meet the specification of requirements identified in chapter

five; the outline design presented in chapter six and has been refined and detailed in this chapter

using two supply chain applications. The methodology is summarised in graphical form in figure

7.1.

133

Phase 1:

Describe the supply

problem

Output: Description of the

improvement(s) to be evaluated,

for a given objective(s) within its

supply setting

Phase 3:

Determine how each

improvement is to be

represented

Output: Description of the core

processes that represent each

improvement

Phase 2:

Determine how each

objective is to be

measured

Output: Description of the core

processes that provide data

used to calculate each

objective

Phase 4:

Determine how the

inputs and their

sources interconnect

within the model and

with its immediate

supply setting

Output: List of inputs and

candidate processes for

possible inclusion in the model

boundary

Phase 5:

Formulate the model

boundary

Output: List of processes and

inputs included in the model

Phase 7:

Document and validate the

conceptual model

Output: A valid description of the

computer model to be developed

Phase 6:

Design the level of detail

necessary to implement

the model

Output: Description of the model

components and

interconnections that represent

the actual practices included in

the model

Point of entry

A formal problem formulation and

structuring methodology or unstructured

problem from client

Build a prototype and

use sensitivity analysis

to extend the model

boundary and level of

detail

Output: Refinement of the

model boundary and level of

detail

Iterate for each PROMOTED process decided in phase five

Figure 7.1 Overview of the SCM

2

The purpose of each phase can be described along with the information that each phase provides

to aid a user in the creation of a conceptual model for SCM applications (in italics below). This

includes an overview of the steps which need to be followed and ‘checks’ that need to be

completed before proceeding to the next step. Iteration is required between steps if a check has

not been satisfied (requires the phase to be repeated), or to initiate a return to a previous step as

new information is generated (in the case of formulating the model boundary).

Point of entry: Enter the methodology when a client has a supply problem to be evaluated

using a simulation approach

Phase one: Describe the supply problem - The supply problem is described from the perspective of

the client

This includes a description of the supply chain improvement(s) to be evaluated (step 1.1)

for a given objective(s) (step 1.2) within the supply setting (step 1.3). Two checks are

made to state how each improvement could achieve each objective (step 1.4) and that

the descriptions provided are ‘correct’ (step 1.5). Simulation would be unsuitable if the

134

improvement could not achieve each objective and thus the improvement is excluded

from the study. The phase cannot be exited until the description of the supply problem is

‘correct’; the phase is repeated otherwise.

Phase two: Determine how each objective is to be measured – The objective is described in terms

of how it will be measured

This includes a description of the decomposed supply chain metrics (step 2.1), how each

performance metric will be calculated from the data sources that have been generated

from the decomposed business processes (treated as ‘core’ processes at the required

level of detail), (step 2.2), and the actors associated with each data source and

measurement span (step 2.3). The description of how each objective is to be measured is

checked for ‘correctness’ (step 2.4) and, therefore, the phase cannot be exited until this

check is complete; the phase is repeated otherwise.

Phase three: Determine how each improvement is to be represented – The improvement is

described in terms of how it is to be represented

This includes a description of the decomposed business processes (treated as ‘core’

processes at the required level of detail) (step 3.1), for each actor (step 3.2). The

description of how each process is to be represented is checked for ‘correctness’ (step

3.3). The phase cannot be exited until this check is complete and, therefore, the phase is

repeated until it is.

Phase four: Determine how the inputs and their sources interconnect within the model and

with its immediate supply setting – Provide a list of model inputs and candidate process elements

(NB supplies information only to formulate the model boundary)

The inputs and their source interconnections for each actor are described for each

process element included in the model (step 4.1) and discriminated against to identify

‘candidate’ process elements (step 4.2). The process is initiated from the included

process elements that are provided from the ‘core’ processes (identified in phase two and

three), followed by the ‘promoted’ process elements (identified in phase five). The phase

cannot be exited until all process elements have been discriminated against (in step 4.2)

135

and, therefore, it is re-entered in subsequent rounds when ‘promoted’ process elements

are identified (from step 5.3).

Phase five: Formulate the model boundary – Provide a list of processes and inputs included in the

model

Each of the inputs from the candidate process elements (listed in step 5.1) are analysed

by two rules for inclusion in the model boundary and the rationale for each decision is

documented (step 5.2). The first includes reaching a decision on: whether the input to be

generated from the candidate process element will affect model behaviour by significantly

impacting on the objectives of study? If the answer is ‘yes’, then ‘include’, if ‘no’, then

‘exclude’, if unsure, ‘test’ (using a prototyping method). The second refers only to those

indicated as ‘include’: can the included input be generated in a simplified form (i.e.

random distribution or fixed value) so that there are no further inputs to the process? If

the answer is ‘yes’, then ‘simplify’, if ‘no’, then ‘promote’. When no further inputs have

to be considered, the ‘promoted’ process elements are returned to phase four for

discrimination. The cycle is completed in rounds until no further inputs and their sources

need to be considered. The list of processes and relationships between inputs to be

included in the model are checked for ‘completeness’ and ‘correctness’. The phase

cannot be exited until this check is complete, phase four and five is repeated otherwise.

Phase six: Design the level of detail to implement each process and input included in

the model boundary – Provide a description of how the actual practices are represented

by the model components and relationships between them

Each process included in the model is described in terms of how it is actually

implemented in practice in sufficient detail of how the inputs (and sources) are

converted to produce an output (to a destination), specified by each actor (step

6.1). This also includes identifying ‘phantom’ process elements by determining

the process elements that contain only a workflow input and no practices can be

identified, that would influence the characteristics of the workflow. These are

not modelled in any detail. The following steps describe how each actual

practice, specified by each actor, will be represented by the components (i.e.

processes; activities and events; entities) in the computer m odel, in the simplest

way (by incorporating any assumptions or simplifications into the descriptions)

136

(step 6.2). There are no checks at this stage as the following phase is a full and

complete validation of the conceptual model (phase seven). The phase cannot be

exited until all actual practices have been represented by the components in the

computer model.

Phase seven: Document and validate the conceptual model – The draft descriptions

provided from the phases and steps in the methodology are documented and validated

The draft conceptual model is documented by describing the supply problem from the

client’s perspective, how each objective is to be measured, how each improvement is to

be represented, how each actual practice is to be represented by the components in the

model and their interconnections, assumptions and simplifications incorporated into the

model component descriptions (step 7.1). Each of the descriptions is validated for

‘correctness’ from the perspective of the modeller, (hypothesis validity), and client,

(credibility). Any issues that arise, results in the necessary revisions and adjustments by

returning to the necessary phase in the methodology (step 7.2). The final step documents

a non-software specific description of the simulation model to be developed (step 7.3).

7.2 Presentation of the development cases

The detailed design has been developed and refined using two development cases which are

representative and typical of complex supply chain problems. Firstly, the BeerCo development

case is used as a typical and simplified application that has been used for many years to teach

(e.g. Kaminsky and Simchi-Levi, 1998; Holweg and Bicheno, 2002; Jacobs, 2000; Sparling, 2002)

and to study supply chains (e.g. Ackere, Larsen and Morecroft, 1993; Lee, Padmanabhan and

Whang, 1997; Disney and Towill, 2003a; 2003b). Secondly, the CarCo development case is a

detailed and extremely complex case that has been developed in an industrial context: an

automotive seat supply chain. This case has been used to compare supply chain simulation

functionality (e.g. Albores et al., 2006), identify methods for evaluating a supply chain problem (in

Weaver et al., 2007) and to select supply chain architecture (Benton, 2009).

7.2.1 Development case 1: BeerCo

The BeerCo development case (Beer distribution game) is considered a good illustration of a real-

life supply chain (Sterman, 1989; Disney and Towill, 2003a; 2003b) and an environment that is

rich, containing four actors in a chain, many feedback loops and time delays (Paik and Bagchi,

2007). In particular, Sterman (1989; 2000) points out that the decision rules describe the actual

decision process very well as it includes the essential features of a stock management procedure.

137

These features include replacement of expected orders, correction of differences between the

desired stock and the actual one, and an evaluation of the supply chain inventory (Paik and

Bagchi, 2007).

Figure 7.2 Structure and flows in the BeerCo development case Source: Paik and Bagchi (2007)

The structure and flows in the game are shown in figure 7.2. The game consists of four actors

directly linked in a supply chain; a factory, distributor, wholesaler and retailer supplying beer.

Beer cannot skip the adjacent position (e.g. the wholesaler orders beer from the distributor and

ships beer to the retailer). The objective of the game is to minimize the total cost for everyone in

the supply chain by maintaining low stocks but managing to deliver all orders. An important

consideration in making decisions is the delay in the movement of beer through the supply chain.

There are two costs involved: inventory holding costs and back order costs. To minimize the sum

of these costs, the cost of having stock (stock holding cost) with the cost of being out of stock,

when a customer orders beer (back order costs) must be balanced. This development case is

described in more detail as the methodology is applied in section 7.3.

7.2.2 Development case 2: CarCo

The CarCo development case is a detailed, complex and contextually rich supply chain problem

that has been extracted from an industrial context (justification for the case was provided in

section 3.3.3). The supply chain under study deals with the supply of seats to CarCo. There are

four echelons involved in the supply chain: the car company (a luxury automobile manufacturer:

LA), the seat supplier (SS), a third party warehouse (operated by a third party logistic provider:

3PL), and two suppliers of seat components (central head-rests: CHR and tracks: T). Figure 7.3

shows the configuration of the supply chain.

138

Figure 7.3 A simplified diagram of CarCo’s supply chain Source: Albores, Weaver, Love and Benton (2006)

The issue that the development case considers in detail is one of planning the supply chain. The

goal is to improve the visibility of demand in the supply chain to impact upon delivery

performance and to reduce supply chain costs. At present there is multiple and contradictory

information being generated by different planning systems at each of the actors locations (e.g.

planning is difficult because the seat supplier receives three pieces of contradictory planning data

from the luxury automobile manufacturer). Due to the inaccuracy of the information provided,

informal planning data is relied upon to achieve the delivery performance targets. There is a need

to improve the coherence of the information flows in the supply system and minimise the impact

of the contradictions in the planning data due to the multiple signals of demand. This

development case is described in more detail as the methodology is applied in section 7.3.

7.3 Application of the development cases to refine and detail the SCM2

The aim of both development cases is to apply them in detail and refine the outline design for the

SCM2 developed in chapter six. Also, align the design to meet the required specification

presented in chapter five (identified from the literature). This includes detailing how each of the

key concepts identified in the outline design is implemented in the methodology and a

justification for the choices made in the design. A list of principles considered from existing

practice and observations made during the refinements, using the two development applications,

are provided in tables for each phase in appendix A. The design choices, considered for each of

the principles/observations, cover a range of aspects such as detailing the:

Procedure for each phase with specific steps that should be followed

Role of the participants in each step

Appropriate means for documenting and representing the description and content of the

conceptual model

Points of entry and exit to and from the phases and steps

Way in which information is used and provided from the methodology

139

In relation to how information is used and provided, the outline design argued that using domain-

knowledge (particularly from the SCOR model) would provide an opportunity to develop more

focused and efficient guidelines for simulation conceptual modelling. The information that can be

provided from SCOR to undertake a step is considered along with ways to use the standard

terminology to provide information (i.e. for use by other steps in the methodology or to describe

the conceptual model).

The two development cases are only applied in detail up to the point that the actual practices are

described (a domain-orientated simulation conceptual model). This is the point at which the

methodology is novel. This means that the description of the model components is not

considered in detail in this chapter, nor is the final documentation of the validated conceptual

model. The steps that correspond to each of these needs incorporate existing practice that is

widely used to describe the model components and their interconnections (these

interconnections were identified in the model boundary formulation). It can be argued, that the

documentation and validation procedure is also novel but is dependent upon how the model

components are described and is a considerable area of study in its own right. To demonstrate

how the methodology can be used in these steps some illustrative examples are discussed from

the BeerCo development case. As previously noted a modeller worldview (e.g. those that are

familiar with DES), experience or skills have a bearing on how the model components are

described (C.f. section 2.4.3).

7.3.1 Phase 1: Describe the supply problem from the client’s perspective

Phase one implements the first key concept identified: a supply chain problem describes the

objective, improvement and supply setting. It initiates the whole conceptual modelling procedure

by describing the supply problem and performs two checks to verify that simulation is suitable for

evaluating an improvement and that the descriptions provided are ‘correct’. There were a

number of observations that were made when implementing key concept one into phase one of

the SCM2. These observations have been highlighted previously by Robinson’s (2004) discussion

of developing an understanding of the problem situation and determining the modelling

objectives. These are considered in light of applying the two development cases and how these

impacts upon the design of the phase in table A.1 in appendix A.

These considerations were included in the formulation of the detail of the phase. In particular,

the applications to the cases demonstrated it was of critical importance to structure and describe

the problem correctly. This is the case because the core components to be included in the model

are derived from the supply problem and the boundary of the model is formulated by considering

140

the relationships between core components and the supply setting. The detail of phase one is

shown in table 7.1.

Table 7.1 Detailed steps for phase one of the SCM2

Phase one: Describe the supply problem from the clients perspective

Process steps Information required Information provided

Point of entry: From client source(s): A structured (from a problem formulation and structuring methodology) or unstructured problem, from the client; From 7.2.1: An invalid description of the supply problem

1.1 Describe the objectives of study, in terms of the impact on supply chain performance attributes, that the improved supply system should achieve

Obtain from the client the desired impact (e.g. minimise, maximise, maintain) on supply chain performance attributes. Use SCOR descriptions of supply chain performance attributes (SCOR V.9, section 3) as a guide

Description of the objective(s) of study

1.2 Describe the alternative [set of] supply chain improvement(s) in terms of how and which actors are affected by the change

Obtain from the client situational information. Use SCOR descriptions of practices (SCOR V.9, section 4) to select and describe each improvement

Description of the alternative improvements to be made to the existing system

1.3

Describe the nature of the setting of the supply problem (e.g. actors in the supply system that have a cause and effect relationship between the improvement and objective, and any important situational information) that may influence the scope of the problem

Obtain from the client information on the general supply problem setting

Description of the supply problem setting

1.4

State the means by which each improvement is to achieve each objective, by bringing about change in the supply system (in terms of desired impact on performance attributes)

Use the information provided from 1.1 – 1.3 to describe the cause and effect relationship between the objective and improvement within the stated supply setting; Use SCOR descriptions of impact of each practice on performance attributes, if the improvement is described as a major best practice (SCOR V.9, section 4). Consult the client on how each improvement will bring about change in the supply system

Description of how each improvement could achieve each objective

1.5 Check that the description provided from steps 1.1 – 4 are ‘correct’ from the perspective of the client making any alterations as deemed necessary before proceeding

Consult with the client on each description (Information provided from 1.1 – 4)

Description of the supply problem from the client’s perspective

Point of exit: To phase 2: Proceed only when the description of the supply problem has been agreed as ‘correct’ To step 7.1: As above and when all other phases have been completed (final validation)

Output: Description of the supply problem from the client’s perspective

7.3.1.1 Step 1.1: Describe the objective(s) of study

The objectives of study can be described in terms of the impact on supply chain performance

attributes that the improved supply system should achieve. In both cases the objectives can be

easily translated into the required supply chain performance attributes using the SCOR

descriptions of typical attributes. The impact is indicated in general terms such as whether the

performance attribute is to be ‘minimised’ or ‘maximised’ in line with most simulation studies

(Beamon, 1998). This can be seen in table 7.2.

141

Table 7.2 Description of the objective(s) of study

BeerCO development case CarCO development case

Description of the objective(s) of study

From step 1.1

1. Minimise total supply chain costs (-) 2. Maintain customer service (-)

1. Maximise supply chain reliability (+)

In the BeerCO development case, the retailer is experiencing high total supply chain costs and

poor levels of customer service due to a lack of planning and control across the supply chain and

between actors. The aim is, therefore, to ‘minimise’ total supply chain costs by reducing

inventory, while ‘maintaining’ customer service. Using SCOR performance attributes, it is obvious

that there are two objectives: to minimise total supply chain costs and to maintain customer

service.

In the CarCO development case, the luxury automobile manufacturer (OEM) needs to ‘minimise’

the impact of contradiction in planning data due to multiple signals of demand which is impacting

upon the reliability of the supply chain. The aim is to improve the coherence of the information

flow to the partners in the seat supply chain. To achieve this, the luxury automobile

manufacturer needs to be supplied seats on time as line stoppages are unacceptable. Using SCOR

performance attributes, it is apparent that there is one objective: to ‘maximise’ supply chain

reliability.

7.3.1.2 Step 1.2: Describe the supply chain improvement(s)

The supply chain improvement can be described in terms of how and which actors are affected by

the change to the supply system. This information is specific to the organisation implementing

the improvement but the extraction of this information can be aided by the descriptions of the

practices provided by SCOR (it was previously noted that over 420 practices exist). There was also

some difficulty ensuring that the correct practices were identified due to different variations in

certain practices and the need to combine more than one for the purposes of describing the

improvement. Although, using the SCOR best practice guide it is worth noting that the

participants (or at least the facilitator) involved in this step needs to be proficient with SCOR and

its terminology. It was important to be clear how the improvement is to be implemented in

practice and by which actor; therefore this was emphasised in the step. For instance, the SCOR

model was clear in how to describe the improvement but not how it will bring about an effect in

the real system. An illustration of the information provided from step 1.2 is shown in table 7.3.

142

Table 7.3 Illustration of the description of the improvements selected

BeerCO development case CarCO development case

Description of the alternative improvements to the existing system

From step 1.2

Enable real-time visibility using an EDI digital link between the wholesaler and distributor to share information on complete finished goods, order status, expected shipments and backlog. The information is used by the distributor to plan deliveries and how orders are placed with the factory.

Providing key participants in the supply chain full visibility of the daily call in (DCI) formulated by the luxury automobile manufacturer. The information is used by the tier three manufacturers (seat headrests and tracks) so that they can adjust their kanban set-up to reflect daily call in (DCI) requirements.

For illustrative purposes, two practices could be identified from the SCOR descriptions that

adequately described the improvements for each development case:

Enable real-time visibility using an EDI digital link between the wholesaler and

distributor to share information on complete finished goods, order status, expected

shipments and backlog (BeerCo case) – This was selected to improve one of the

underlying effects of the bullwhip effect by improving information sharing between actors

in the supply chain (e.g. Lee et al., 1997a, 1997b; Mason-Jones and Towill, 1997; Chatfield,

Kim, Harrison and Hayya, 2004; Steckel, Gupta and Banerji, 2004; Croson and Donohue,

2005; Ouyang, 2007). There were many practices for information sharing. The one to be

selected had to reflect who implements the practice and what information is visible and

how it is used (i.e. distributor uses the information to plan deliveries and how orders are

placed with the factory).

Provide key participants in the supply chain to have full visibility of customer demand -

This was selected to improve the coherence and sharing of actual demand further

upstream. The description was improved by describing the means of providing demand

(i.e. the daily call in), from a particular actor (i.e. LA) and how the information is used (i.e.

by SS and T so that they can adjust their kanban set-up to reflect the daily call in

requirements).

7.3.1.3 Step 1.3: Describe the supply setting

The supply setting is specific to the actual supply system being examined. Therefore, information

can only be obtained from the client (or more specifically SMEs). The aim here is to identify the

client’s perspective on the scope of the problem and, in particular, the actors to be included in the

analysis. The actors to be included in the model should have a cause and effect relationship. The

cause is the improvement that is implemented to bring about a change in the supply system and

the effect relates to how the impact of the change is measured. A later stage (formulation of the

model boundary) determines the necessary interconnections between the improvement,

objective and the supply setting. An illustration of the information provided from step 1.3 is

shown in table 7.4.

143

Table 7.4 Illustration of the description of the supply problem setting

BeerCO case CarCO case

Description of the supply problem setting

From step 1.3

The scope of the investigation is determined by:-

Actors in supply system: retailer, wholesaler, distributor and factory)

Product: units of beer supplied downstream in a chain

The scope of the investigation is determined by:-

Actors in the supply system: luxury automobile manufacturer (LA), seat set manufacturer (SS), third-party Logistics Company (3PL), central headrest manufacturer (CHR) and track manufacturer (T).

Product: seat set consisting of front and rear seats delivered as a module to the luxury automobile manufacturer, in the fabric specified by the end customer

Both development cases were described in terms of the actors in the supply system and the

product that flows through the system. In the BeerCo development case, four actors are included

so that the impact of the improvement can be measured in terms of the ‘total supply chain cost’.

The boundary would be drawn differently if only the ‘customer service’ measure was used. This is

because the boundary would be drawn between the retailer (places orders to be satisfied);

wholesaler (measure how customer service is maintained, implements improvement) and the

distributor would also be included because it is affected by the improvement. Similarly, the CarCo

development case consists of five organisations. These are included because the improvement

includes the LA sharing information with the two tier three suppliers so that they can adjust their

kanban set-ups. The supply chain would need to include all critical links between the actors

involved in the supply of a seat set to the LA to demonstrate the impact of the change upon

delivery performance.

7.3.1.4 Step 1.4: Description of how each improvement will achieve each objective

This step was included as a useful means of justifying the inclusion of the improvement as part of

a simulation study, aid in the determination of the model boundary and for validating the model

in later phases. This was a more difficult step to complete as it forces the participants to be clear

on how the change is to be brought about in the system. This is considered by stating the means

by which the improvement is to achieve each objective. An illustration of the information

provided from step 1.4 is shown in table 7.5.

Table 7.5 Illustration of how each improvement could achieve each objective

BeerCO case CarCO case

Description of how each improvement could achieve each objective

From step 1.4

The distributor decides how much to order from the factory and deliver to the wholesaler based upon visibility of stock, orders, shipments and backlogs. This will impact upon the amount of inventory required (and the associated cost of inventory) to satisfy customer orders “in-full” as stock-outs are unacceptable.

Adjusting the CHR and T master production schedule based upon the DCI (information flow) to effect the reliability of delivered materials to the LA

In the BeerCo development case the improvement to share information between the wholesaler

and distributor is not useful unless it states what the information is and how it will be used.

Likewise in the CarCo development case sharing actual demand further upstream is meaningless

144

unless it states who receives the information and how it will change the way suppliers plan their

operations. SCOR can provide information on the typical impact that a practice can have on the

range of performance attributes described in SCOR. In these development cases the modeller can

use this information to describe how the improvement could achieve the objective and be

satisfied that it should be included in the simulation study. The problem is that this has only been

completed for a select number of key business practices so it is likely that the information is

sourced directly from the client. It is clear that forcing the modeller to express the improvement

in terms of how it will impact upon an objective, provides a useful check that the improvement

should be included and can be used for validation purposes in later phases.

The modeller in the BeerCo development case must be clear that the information aids ‘the

distributor to decide how much to order from the factory and deliver to the wholesaler, to reduce

supply chain cost while maintaining reliability’. Improving visibility between the wholesaler and

the distributor in the BeerCo case should enable the distributor to receive demand, stock and

shipping information, without an order delay. This information can be used to keep finished

goods inventory stock low so as to satisfy future demand without stock-outs.

For the CarCo development case, the improvement enables the ‘tier three suppliers’ (central

headrests and tracks) to adjust their master production schedule based upon the DCI (information

flow) to affect the reliability of delivered materials to the luxury automobile manufacturer’. The

CarCO case improvement will improve reliability to the luxury automobile location because

communicating the DCI will enable the tier three suppliers to plan production and delivery

requirements based upon LA demand (reduced demand contradictions and real demand from

source).

7.3.1.5 Step 1.5: Draft and check the description of the supply problem

This step was added in order to draft a description of the supply problem and check with the

client that the problem is understood and has been agreed between the participants. During the

design of this phase it was clear when applying the two development cases that if the problem

was not described correctly then the proceeding analysis would be flawed. Likewise, the

description of how each improvement is to be represented and how each objective is to be

measured could not be derived if the information was not provided in the structured way.

7.3.2 Phase 2: Determine how each objective is to be measured

Phase two implements the second key concept identified in the outline design: ‘SCOR SCM

performance metrics can be used to identify how an objective is to be measured’. The phase is

145

entered only when the supply problem has been described and been agreed as ‘correct’. This is

important as the information required by the phase is gathered from the description of the

objective of study. The observations made when refining and detailing this phase are presented

in table A.2, in appendix A. with an overview of how they influenced the design.

The development case applications showed that it was relatively straight-forward to describe how

the improvement is to be represented using SCOR. An hierarchy of metrics is presented in SCOR

for each supply chain performance attributes which are described in significant detail (example of

the reliability metric is shown in figure 7.2). The modeller needs to select the metrics and extract

the relevant information from the descriptions of each metric. Critically, the data sources are

provided that will drive each calculation. These are used to derive the core processes

(components) that are to be included in the model. There was some situational information

required which included describing where the metric are to be measured. The rationale for this is

that it would not be possible to identify the interconnections between actors in the supply

problem if they are not described. The procedure to follow had to aid in the extraction of the

SCOR information by selecting the metrics relevant for the performance attribute and extract the

calculations, data sources and how the metric is measured and where. These considerations were

included in the formulation of the detail of the phase, shown in table 7.6.

146

Table 7.6 Detailed steps for phase two of the SCM2

Phase two: Determine how each objective will be measured

Process steps Information required Information provided

Point of entry: From phase 1: Description of the objective(s) of study (information provided from step 1.1)

2.1

Specify the supply chain performance measures for each objective, in the context of how each objective is to achieve each improvement

2.1.1 Specify the high level strategic level 1 metrics associated with each performance attribute

Use SCOR level 1 strategic metrics (SCOR v.9, section 2) to decompose each supply chain performance attribute. Objective(s) of study (from 1.1). How each objective is to achieve each improvement (from 1.4)

Hierarchy of supply chain metrics to measure each objective

2.1.2 Specify (if any) the level two metric(s) that provide the lower level calculations for each higher level strategic level one metric

Use SCOR level two diagnostic metrics (SCOR v.9, section 2) to decompose each level 1 metric if necessary. How each objective is to achieve each improvement (from 1.4)

2.1.3 Specify (if any) the even lower level three diagnostic metric(s) for each higher level metric

Use SCOR level three diagnostic metrics (SCOR v.9, section 2) to decompose each level two metric if necessary. How each objective is to achieve each improvement (from 1.4)

2.2

Define how each performance metric will be calculated from the data sources that are used to drive the calculation

2.2.1 Define the calculation for each metric

Use SCOR metric calculation descriptions for each metric (SCOR v.9, section 2)

List of calculations and data source requirements for each metric

2.2.2 Specify the processes that generates each data source for each metric

Use SCOR data collection descriptions for each metric (SCOR v.9, section 2)

2.3 Define the nature of the measurement for each supply chain performance metric

2.3.1 Specify the actors associated with each data source process

Derive from the supply problem statement (from phase 1) and class of measures (from 2.1)

Definition of the nature of measurement for each metric

2.3.1 Specify the measurement span for each performance metric

2.4 Check that the outputs provided from steps 2.1 – 2.3 correctly interpret the objective(s); make any alterations as necessary before exiting phase two

Check the outputs from 2.1 – 2.3 with the objective described in 1.1, if necessary confirm with the client

Description of how each objective will be measured

Point of exit: To phase 3: Proceed only when the description of how each objective that will be measured is agreed as ‘correct’

Output: Description of how each process is to provide data used to calculate each objective

These considerations were included in the formulation of the detail of the phase. In particular the

applications to the cases demonstrated it was of critical importance to structure and describe the

problem correctly. This is the case because the ‘core’ components to be included in the model

are derived from the supply problem and the boundary of the model is formulated by considering

the relationships between ‘core’ components and the supply setting.

7.3.2.1 Step 2.2: Specify the class of SC performance measure for each objective

The objective that is described in terms of the impact upon a supply chain performance attribute

can be decomposed into specific performance metrics at the desired level of detail. SCOR

provides a hierarchy of metrics for each performance attribute. An example of the hierarchy of

metrics for the reliability performance attribute is shown in figure 7.4. The modeller will need to

147

decide upon the metric at the different levels of decomposition that are most suitable to measure

how an objective will have an impact upon an objective. It was evident from the applications that

the correct metric needs to be defined otherwise the data sources provided will be incorrect. This

resulted in the need for a check at the end of the phase.

Figure 7.4 ‘Reliability’ metric structure with an example of a level 3 metric Source: SCOR Supply Chain Operations Reference Model Version 9.0 (2008, section 2.1.2 and 2.1.13)

The BeerCo objective can be broken down into one high level strategic metric and two diagnostic

metrics. At level 1 ‘CO.1.1: total supply chain management costs’ are calculated from a level two

metric, ‘AM.2.8 Inventory: capital employed in finished goods stock’. The description of how an

improvement is to achieve an objective specifies that orders must be delivered in full as stock-

outs are unacceptable. There are many reliability metrics but the one associated with the “in-full”

aspect is ‘RL.2.1 % of orders delivered in full’. The CarCo objective refers to the luxury automobile

manufacturer receiving seat sets on time to the specific daily call in requirements. Therefore, a

level 3 metric ‘RL.3.20 % orders received on-time to demand requirement’ can be identified from

the SCOR description of metrics (see figure 7.4 above). A summary description of the supply

metrics for both cases can be seen in table 7.7.

Table 7.7 Description of the supply chain metrics

BeerCo development case CarCo development case

Hierarchy of supply chain metrics to measure each objective

From step 2.1

1. R.L.2.1 % of orders delivered in full 2. CO.1.1 Total supply chain

management cost 3. AM.2.8 Inventory: Capital

employed in finished goods stock

R.L.3.20 % orders received on-time to demand requirement

148

7.3.2.2 Step 2.3: Define how each performance metric will be calculated from the data

sources

This step is included as it provides information on how a performance metric is to be calculated

and the data sources that provide the necessary information to drive the calculation. This is

important because the processes and the information it provides are critical components that

need to be included in the model boundary. For each of the metrics described in the previous

steps, it was easy to extract the corresponding information from the SCOR descriptions for each

performance metric (figure 7.5 provides an extract from the SCOR metric descriptions to describe

how to calculate the metric, what data is required and from which components). It must be

noted that this can only be completed successfully if the correct metrics have been selected. A

summary description of how each performance metric will be calculated from the data sources

for both cases can be seen in table 7.8.

Figure 7.5 Calculation and data collection needs for RL.2.1 % of orders delivered in full Source: SCOR Supply Chain Operations Reference Model Version 9.0 (2008, section 2.1.3)

The RL.2.1 % of orders delivered in full is driven by data primarily associated with the original

order processing step of ‘Reserve inventory and determine delivery date’ (D1.3), inventory

availability (M1.1) including location accuracy (ED.4), and the satisfaction of that commitment

through shipment and customer receiving processes (D1.12, D1.13). In the BeerCo development

case the wholesaler does not manufacture the product, so this can be ignored, but stores stocked

product which is satisfied by the D1.3 process. SCOR provides a definition of the calculation to

include [total number of orders delivered on the original commitment date]/ [total number of

orders delivered] x 100%. The data collection needs, for the total supply chain cost is calculated

from the sum of A.M.2.8 inventory at each actors ‘receive product from source’ (D1.8) process,

expressed in dollars. The level 2 metric used to calculate ‘orders received on time to demand

requirement’ in the CarCo problem is collected from ‘receive product from supplier’ (S1.2). SCOR

defines the calculation for this as the number of orders that are received on-time to the demand

requirements divided by the total orders for the demand requirements in the measurement

period.

149

Table 7.8 Description of calculation and data source requirements for each metric BeerCo development case CarCo development case

List of calculations and data source requirements for each metric

From step 2.2

1. [Total number of orders delivered on the original commitment date]/[total number of orders delivered] X 100%

2. Sum of finished goods inventory stock cost at each actor location

3. The amount of finished goods inventory (stock) on hand to support customer service, expressed in dollars

The number of orders that are received on-time to the demand requirements divided by the total orders for the demand requirements in the measurement period

7.3.2.3 Step 2.4: Define the nature of measurement for each performance metric

The nature of the measurement for each performance metric is included to ensure that the

modeller pinpoints the actor who calculates the metric across a particular measurement span

(e.g. activity, process, organisation, and supply chain). Failure to do so will mean that it will not

be possible to formulate the model boundary from the core processes and data requirements

identified.

The BeerCO objective is to understand the impact of the improvement on the delivery reliability

from the wholesaler to the retailer. Inventory cost is calculated from the factory, distributor,

wholesaler and retailer. Therefore, only the wholesaler includes the process element (ED.4 –

manage finished goods inventories, D1.3 - reserve inventory and determine delivery date, D1.12 -

ship product and D1.13 - receive and verify product by customer) associated with the R.L.2.1 % of

orders delivered In full metric; and all actors include D1.8 - receive product from source or make

to calculate CO.1.1 - total supply chain management cost and AM.2.8 - inventory metrics. The

CarCo objective (RL.3.20 - % orders received on-time to demand requirement) is concerned with

the reliability of deliveries at the luxury automotive location (S1.2 – receive product); no metrics

are calculated at any other actor location.

Table 7.9 Description of the nature of measurement for each metric in both development cases BeerCo case CarCo case

Description of the nature of measurement for each metric

From step 2.3

1. D1.3, D1.12, D1.13 (wholesaler process)

2. D1.8 (all actors – supply chain) 3. D1.8 (Factory, distributor,

wholesaler, retailer – process)

S1.2 (Luxury automobile manufacturer – activity)

7.3.2.4 Step 2.5: Check the descriptions in phase two for ‘correctness’

A check is required at the end of phase two to ensure that the metrics selected in step 2.1

correctly interpret the objective(s) described in step 1.1 and that the associated detail has been

described accurately. Of particular importance is defining the actors that provide each metric as

this is specific to the supply setting. SCOR only provides data sources from within one

organisation. This is important because the formulation of the model boundary is founded on

identifying the interconnections between processes and with actors in the supply setting. The

150

applications showed that an incorrect description of how each objective is measured with the

appropriate details will not allow the model boundary to be determined successfully.

7.3.3 Phase 3: Determine how each improvement is to be represented

Phase 3 implements the third key concept identified in the outline design: SCOR practices can be

used to describe each improvement to be evaluated. The phase is entered after successfully

completing phase two although it is not dependent upon this phase. It can only be entered when

the supply problem has been agreed as ‘correct’ in phase one. This is important as the

information required by the phase is gathered from the description of the improvement(s) (step

1.2).

There were seven observations made when implementing key concept three into phase three of

the SCM2, shown in table A.3 in appendix A. These principles/observations are included in the

design of phase three, shown in table 7.10.

Table 7.10 Detailed steps for phase three of business methodology

Phase three: Determine how each improvement is to be represented

Process steps Information required Information provided

Point of entry: From phase 2: Enter phase three when the description of each objective that will be measured is agreed as ‘correct’. The information required from a previous step includes the description of the improvement(s) provided in step 1.2. Participants note: Phase three is not dependent upon the output from phase two, it could be completed simultaneously but phase four cannot be initiated until both phase two and three is complete

3.1

Define the level of process detail for each supply chain improvement option

3.1.1 Specify the level 1 top level (process types) that define the scope and content

Use SCOR v9.0 best practice guide described in section 4 to identify process types associated with each improvement identified in phase one. If no practices can be identified for each improvement then the processes must be selected that are critical to represent each improvement (verified with client sources). Consult the client on how each improvement will affect the supply system – the effect of each improvement (on processes in the supply system) also needs to be included in the description of the improvement

List of processes at three levels of process detail that represent each supply chain improvement option

3.1.2 Specify the level 2 configuration (process categories) to implement an organisation operations strategy

3.1.3 Specify the level 3 process elements (decomposed processes) that “fine tunes” an organisations operations strategy

3.2 Specify the actor(s) associated with implementing each business process

Derive from phase one statement of the supply problem, verified with the client if necessary

List of actors associated with each business process

3.3 Check that the outputs provided from steps 3.1 – 3.2 correctly interpret the improvement(s); make any alterations if necessary before proceeding

Check the outputs from 3.1 – 3.2 with the improvement(s) described in 1.2; if necessary confirm with the client

Description of how each objective will be measured

Point of exit: To phase 4 Proceed only when the description of how the processes represent each improvement is ‘correct’

Output: Description of how the processes represent each improvement

Similar to phase two the cases show that the steps are relatively easy to follow with information

provided by SCOR practices. It is important to note that this phase can only be completed if the

improvement(s) have been described in enough detail and verified with the client. The phase not

only provides the processes and actors that need to be included in the model but also provides an

151

indication of the level of decomposition necessary to evaluate each improvement. The processes

identified are treated as ‘core’ processes that are used as a starting point to formulate the model

boundary.

7.3.3.1 Step 3.1: Define the level of process detail for each improvement

The level of process detail for each improvement can be obtained from the SCOR practice

descriptions. This is the case if the described improvements are aligned to one or more practice

described in SCOR. If this is not the case the process descriptions need to be used to identify

which processes would need to be represented for each improvement. Likewise, for the

description of objectives, SCOR only describe the processes. The user must decide who is

responsible for implementing each process. These requirements have been incorporated into the

steps.

Figure 7.6 Extract of the SCOR descriptions of best practices Source: SCOR Supply Chain Operations Reference Model Version 9.0 (2008, section 4.1.50)

The BeerCo development case covers two practices in SCOR in relation to the visibility of

information and how the information will be used by the distributor. The process that represents

the visibility of information from the wholesaler includes D1.2 (receive, enter and validate order)

152

and D1.3 (reserve inventory & determine delivery date). This information is used by the

distributor to plan deliveries (P4: plan deliveries) and decide how orders are to be placed with the

factory (P2: plan source). On the other hand, the information to be shared (daily call in) in the

CarCo case is generated by the P2 (plan source) and sent via a replenishment signal that

continuously broadcasts the target launch sequence (S1.1: schedule product deliveries). This is

received by the tier 3 manufacturers (central head-rests and tracks) so that they can adjust their

kanban set-up to reflect daily call in requirements (P4: plan deliver).

Table 7.11 List of processes at three levels of process detail that represent each SCIO

BeerCo case CarCo case

List of processes at three levels of process detail that represent each supply chain improvement option

1. Level 3 (process element): D1.2 (Receive, enter and validate orders); D1.3 (Reserve inventory & determine delivery date)

2. Level 2 (process category): P2: (plan source); P4 (plan deliver)

1. Level 2 (process categories): P2 (plan source); P4 (Plan deliver)

2. Level 3 (process elements): S1.1 (Schedule product deliveries

7.3.3.2 Specify the actor(s) associated with each process

The specification of the actors associated with each process can be completed at the same time as

step 3.1. The descriptions provided in the previous section illustrate how the actors are to be

affected by each improvement. The step needs to be included as the actor associated with each

process is specific to the situation. An observation can be made about SCOR when describing

business practices; it would be useful if SCOR could indicate how practices are implemented by

processes across different actors. In some cases, such as VMI (c.f. section 5.1) the improvement

makes it explicit that some process elements are implemented in the supplier (or even the

customer) as well as the organisation. Therefore, this step is made explicit to ensure that the

actors are correctly identified as this has a bearing on the analysis that forms the model

boundary.

Table 7.12 List of actors associated with each business process

BeerCo case CarCo case

List of actors associated with each business process

1. Implemented at the wholesaler

2. Implemented at the distributor

1. P2 implemented at the Luxury automotive manufacturer; P4 implemented at both the central-headrest and tracks tier 3 suppliers

2. Implemented at the luxury automotive manufacturer

7.3.3.3 Check the outputs in phase three with the improvement(s)

A check is needed to ensure that each improvement has been correctly interpreted into SCOR

business processes. In the two cases this was relatively straight-forward as the improvements

were aligned with existing SCOR practices. Ensuring the correct actors is listed for each business

process should be checked and, if necessary, verified with the client. If an improvement is not

described by SCOR, or even, more than one practice is used, then it is necessary to justify why

153

each process is said to be critical as this has a direct bearing on the formulation of the model

boundary.

7.3.4 Phase 4: Determine how the inputs and their sources interconnect

Phase four implements two key concepts, four and five identified in the outline design:

Identification of the core processes that need to be modelled, their inputs generated from

a source process element

Process elements that have yet to be included in the model can be classed as candidates

for possible inclusion

The phase is entered in the first instance from both phase two (processes that provide a data

source) and phase three (processes that represent each improvement) which provide information

on the process that need to be included. These are classed as the ‘core’ process elements to be

included in the model. The processes are critical and the interconnections between these

processes in the supply setting need to be determined to formulate the model boundary. SCOR

describes the inputs to each process therefore, the relationships (interconnections) between

processes can be determined. The importance of the step is to identify interconnections that

have not been included so that they can be considered for possible inclusion based upon rules

that aid the formulation in the model boundary (in phase 5). There is also a second point of entry

in phase four, from phase five, when a process has been ‘promoted’ for inclusion in the model.

These ‘promoted’ process elements must be treated in the same fashion as ‘core’ process

elements. During the process of promoting process elements it is expected that these may have

already been included so they no longer need to be treated as ‘candidates’ for possible inclusion.

There were eleven observations made when implementing key concepts four and five into phase

four of the SCM2, shown in table A.4 in appendix A. These principles/observations are included

into the design of phase four, shown in table 7.13.

The development cases demonstrate that the phase involves the most time to extract and to

identify the candidate processes. However, the processes and relationships described by SCOR

can be used as a way of identifying the critical links between the improvements and the objectives

and those in the supply setting. This satisfies one of the most difficult aspects of conceptual

modelling; determining the components and interconnections that need to be included in a

model. In this phase it is the case of discriminating between processes and inputs that are

included in the model or not. This requires no interaction with the client or great effort other than

discriminating inputs to identify candidate processes. Additionally for both the development

154

cases it provided a starting point to begin the analysis aided in the determination of the model

boundary.

Table 7.13 Detailed steps for Phase 4 of the SCM2

Phase 4: Determine the model inputs and source process elements within the model and with its immediate supply setting

Process steps Input to step Output from step

Point of entry: From phase 3: Enter phase four when the description of how the processes that represent each improvement have been confirmed as ‘correct’ From phase 5: The phase is re-entered to consider each ‘promoted’ process element identified in phase five

4.1

List the inputs fed to each process element included in the model

4.1.1 List all the process elements included in the model

From phase two and three for core process elements. Phase five for promoted process elements.

List of inputs to each process element included in the model, their source process elements, specified by actor

4.1.2 Add the inputs to be fed to each process element included in the model

Use SCOR (SCOR, v.9 section 3): Processes to identify the input descriptions for each process element

4.1.3 Add the source process element that generates each input to be fed to a process element included in the model, consolidating the list where possible

As above

4.1.4 Specify the actor that generates the input from the source process element

As above, but specify the actor using the description of the supply problem as a guide (from step 1.4 - verify with the client if necessary)

4.2 Discriminate the source process elements that generate each input to be fed from a process element included in the model

Verify using output from step 2.4 and 3.3

List of model inputs and candidate process elements for possible inclusion in the model

Point of exit: To phase 5: Proceed when all source process elements have been discriminated. The phase is complete after each round and when no further processes are ‘promoted’ in phase 5.

Output: List of model inputs and candidate process elements

7.3.4.1 Step 4.1: List the inputs fed to each process element included in the model

It was relatively straightforward to list the inputs and source process elements for each included

process element. This was because SCOR describes the relationships between processes and the

task involves assembling the information in a meaningful way. An example of S1.1 which is a core

process element in the CarCo development case and promoted in the BeerCo development case is

shown in figure 7.7.

Figure 7.7 Example of the inputs of a source process element described in SCOR Source: SCOR Supply Chain Operations Reference Model Version 9.0 (2008, section 3.2.5)

155

SCOR provided all the configurations (for MTO, MTS and ETO environments) which is useful but

multiplied the analysis. Although both the BeerCo and CarCo development cases had MTS

configurations it could be envisioned that multiple environments could be used. To eliminate the

number of entries it was noted in the procedure that different environments can impose the

interconnections to be selected. For both the BeerCo and CarCo development cases the MTO and

ETO interconnections were ignored.

It was found that it was not clear how each process element could connect with a process

element, with another actor. For instance, S1.1 (schedule product delivers) has an output that

generates the procurement signal to the supplier but does not state how this signal is received by

the supplier (see figure 7.7). It is the D1.2 (receive, configure, enter & validate order) process at

the supplier location which receives the customer replenishment signal, deliver contract terms

and customer order. Due to the generic nature of SCOR this link is not made explicit. Therefore,

there was a need to walkthrough each of the SCOR interconnections and produce a set of

documents for each of the production environments and clear up any loosely defined

interconnections. These data files were formatted to support the analysis in phase four which

speeded up the process considerably. An extract of S1 source stocked product is shown in figure

7.8.

Figure 7.8 Process elements, inputs, source process element and suggested source actor

156

The presentation of the information was also important. The SCOR detail had to be

supplemented with the actors associated with the source and destination process element. For

instance, in both cases information is being supplied from a source external to the organisation.

This requires the modeller to verify each input source and destination process elements.

Additionally, the presentation of the information needed to ensure that there was no unnecessary

duplication. The BeerCo development case generated a list of 371 entries, while the CarCo

development case included 402 entries without any duplication. This was considerably higher

when all production environments were included in the analysis. An extract of the

interconnections considered for the S1.1 process element in the CarCo development case is

shown to demonstrate the standard layout adopted, in figure 7.9. A solution to this problem is

discussed in the section 7.4 (by automating the process).

Figure 7.9 Extract of the list of inputs considered for S1.1 in the CarCo development case

7.3.4.2 Step 4.2: Discriminate the source process elements

It was straightforward to discriminate the source process elements to identify if they had been

included in the model. This was addressed by asking whether the source process element (that

generates each input to be fed to an included process element) currently exists in the model. This

presented no problem as long as the data was presented in a standard format (shown in figure 7.9

and figure 7.10).

157

Figure 7.10 Extract of how phase four was completed for the CarCo development case

Each input had to be treated separately due to most being an input to more than one process and

the complexity of different actors. It was found that it was the combination of source process

element, actor and input that was being discriminated against. For instance, figure 7.8 shows S1.1

(schedule product deliveries) as an input to the ‘replenishment signal’ which can be sourced from

both M1.2 (issue material) and D1.3 (reserve inventory and determine delivery date). Another

example includes S1.1 as an input ‘logistic selection’ that is considered in both the LA and the 3PL.

7.3.5 Phase 5: Formulation of the model boundary

Phase five implements two key concepts, six and seven identified in the outline design:

Candidate process elements are considered in turn for inclusion in the model, as they form

a critical interconnection between the processes and the real world

Included process elements are considered in turn to identify those that could be simplified

The boundary is formulated by deciding whether an input fed from a candidate process should be

included or excluded from the model and whether it could be simplified (e.g. fixed value or simple

distribution). The phase is entered from phase four where candidate process elements and their

inputs, that interconnect with processes that have yet to be included, are identified. It is exited

for two reasons: firstly, when a candidate process element has been ‘promoted’ it triggers the

need for iteration (to repeat phase four based upon additional information) and secondly, when

no more process elements have been identified (to phase six). There were sixteen observations

made when refining and implementing the two key concepts into phase five, shown in table A.5 in

appendix A. These observations were incorporated into the phase shown in table 7.14.

158

The development case demonstrates that the phase structures the decision process, uses domain

knowledge to identify interconnections between processes and provides a means to document

any justification for the decisions made (i.e. simplified, promoted, tested or excluded). The

decision rules that were considered for each input and candidate process were subjective but it

could be observed that participants could benefit greatly from the information provided from

SCOR. It provides a focus for participants to identify any misunderstandings and need for

clarification which would involve consultation with the client (particularly SMEs). On the whole

the boundary could be identified relatively easily and efficiently using domain knowledge.

Particularly, the interconnections have been defined by SCOR, which can be used to form a

detailed understanding of what needs to be included in the model (included processes need to be

modelled in detail, simplified inputs can be represented as a fixed input or distribution). The

process elements that needed to be included but could be simplified indicated the boundary of

the model.

159

Table 7.14 Detailed steps for phase 5 of the SCM2

Phase 5: Formulate the model boundary

Process steps Input to step Output to step

Point of entry: From phase 4: Proceed in successive rounds between phase four and five when the candidate process elements have been identified. If there are no candidates to be considered then no further iteration is necessary.

5.1 List all the inputs generated and fed by each candidate process element, specified by each actor (if necessary)

Use the list of candidate process elements from 4.2.1 and 4.2.2, list of inputs from 4.1.1, Derive actors from 2.2 and 3.2

List of inputs fed from each candidate process element (for each actor)

5.2

Determine whether to simplify, promote, test or exclude each candidate process element by applying rule 1 and 2

5.2.1 SIMPLIFY candidate process element that WILL generate inputs that will effect model behaviour by significantly impacting on performance measures AND CAN be simplified in a simplified form (either a fixed value or distribution)

Use the SCOR input descriptions (SCOR v.9, section 3) and verify with the client if necessary

List of SIMPLIFIED, PROMOTED, TO TEST or EXCLUDED process elements/inputs with justification

5.2.2 PROMOTE candidate process element that generate inputs that will effect model behaviour by significantly impacting on the performance measures AND CANNOT be simplified in a simplified form (either a fixed value or distribution)

5.2.3 TEST candidate process elements if a decision cannot be made about whether the input to be generated will have an effect on model behaviour by significantly impacting on performance measures

5.2.4 EXCLUDE candidate process elements if the inputs to be generated WILL NOT affect model behaviour by significantly impacting on performance measures

5.2.5 For each decision provide some rationale and justification for the choice made

5.3 If any process elements were PROMOTED in step 5.2.2 then repeat phase four and five until no process elements can be included in the model and inputs to be fed can be SIMPLIFIED.

If any process elements were PROMOTED then go to phase four and steps 5.1 – 3; When no process elements can no longer be PROMOTED then proceed to step 5.4.

5.4

Check that there are sufficient and correct linkages between processes and inputs included in the model and that there are no isolated process elements in the model

5.5.1 In a table list each actor and note which CORE and PROMOTED process elements and SIMPLIFIED input are included in the model

Use Information from step 1.5 and 2.4 (core process elements); step 5.2 (promoted process elements and simplified inputs)

List of processes and inputs included in the model specified by actor

5.5.2 For each improvement that could achieve each objective. Trace the inputs from processes that provide data sources to drive the calculation for each objective to the point that a sufficient and correct link is made with the processes that represent an improvement. Use the table to tick off each process that provides a link.

Use information provided from step 1.4 (description of how each improvement could achieve each objective); 5.2 (interconnections between processes and inputs)

5.5.3 Any remaining ‘isolated’ processes and simplified inputs should be checked using the justifications provided to verify that they are necessary as they effect model behaviour by having a significant impact upon the objectives of study

step 5.3 (justification for each decision)

5.5.4 If any isolated process elements or inputs exist that cannot be justified then return to step 5.2.

Use information from 5.5.3

Points of exit: To phase 4: Iterate between phase 5 and 4 for each ‘promoted’ process identified in phase five. The iteration is no longer necessary when there are no more inputs to be considered. To phase 6: Proceed when there is sufficient linkages between the processes in the model and the supply setting

Output: List of processes and inputs included in the model

160

7.3.5.1 Step 5.1: List all the inputs generated and fed by each candidate process element

The list of inputs generated and fed by each process element could be obtained from the

information provided from phase four. The key decision made in the design of this step was how

to present the information so that it is compatible with the preceding analysis. In earlier versions

the table was formatted to present the candidate process element, input it feeds to a process that

is already included in the model. This involved changing the way in which the data was displayed.

It was decided to use an identical format used in phase four so that the material could be easily

extracted. An example of the information that was extracted when considering the inputs fed to

both D1.2 and D1.3 for the warehouse in the BeerCo development case is shown in figure 7.11. It

can be seen that two interconnections already exist but twelve need be considered for inclusion

in the model boundary. Only the information for candidates was transferred to the table in phase

five.

Figure 7.11 Extract of the output from phase four that is transferred (in step 5.1)

The step was considerably time consuming as it involved manually selecting entries that were

indicated as ‘no’ and transferring this to the table in phase five. It was speeded up by considering

the format of the layout and completing the stages in rounds (iterating between phase four and

five, when candidate processes are promoted). The process was necessary and benefited greatly

from using the relationships described between processes in the SCOR model but it was observed

that this step could involve no human interaction. It could be effectively automated meaning no

effort from participants (discussed in section 7.4).

161

7.3.5.2 Determine whether to simplify, promote, test or exclude each candidate process

element

At the heart of the methodology is the decision of how to determine the model boundary. The

only guidance that is offered is in Robinson (2004, pg. 84) which included in the observation list in

appendix A. This is achieved by applying two rules to each input from a candidate process

element. The issue was to determine which interconnections were critical, to ensure a sufficient

link between the processes included for each improvement and the metric it has an impact upon.

In addition, to identify process elements that needed to be tested because a judgment could not

be reached, and to exclude any unnecessary processes.

The key issue in this step was to determine how to treat each interconnection between the

components included in the model and the supply setting. The decision is subjective but can

benefit significantly by having the necessary information at hand. Two sources exist for this

information from SMEs and utilisation of the descriptions in SCOR. The aim was to identify a way

in which to provide a sufficient link between the ‘core’ processes that represent an improvement

and how this impacts upon the processes that provide the data required to calculate a metric (C.f.

section 4.1.1).

In the case of BeerCo the improvement was being made by the wholesaler, but influencing the

way in which the distributor planned its deliveries, and how it is ordered. Hence all critical

processes between the wholesaler inventory reservation, shipping and receiving processes that

provide information to the distributors plan, source, and deliver processes need to be made. The

BeerCo development case measures the impact of the improvement in relation to the total cost of

inventory at each of the actors and the wholesaler delivery performance. The links therefore had

to include the previous processes and the ‘receive product from source’, at each actor (this

included an output that determined how much inventory was available), the wholesaler inventory

reservation (D1.3), product shipping (D1.12), and receiving at the retailer (D1.13), to fulfill the “in-

full” aspect of the metric. There were a host of processes that needed to be considered to

demonstrate this link. The model boundary steps were able to take the participants through the

process, by considering each connection in turn. This was satisfactorily achieved by asking the

question: Will the input, to be generated from the candidate process element, effect model

behaviour by significantly impacting on the objectives of study?

In both development cases there were a considerable number of interconnections to consider

(288 in the BeerCo development case and 354 in the CarCo development case). The main reason

162

for this is that SCOR has specific entry points (e.g. sending an order to a supplier) and exit points

(e.g. installing product to a customer) between actors. This led to all the links between these

points being considered in light of the problem even when the value added by a particular process

is not significant and adds unnecessary details. This was seen most notably in the CarCo

development case, when the improvement is between the luxury automobile manufacturer and

the tier 3 suppliers, with no core process elements in the third party logistic supplier or the seat

supplier. This resulted in the need to introduce an additional concept, by effectively treating a

link, which performs activities that will not have an effect on model accuracy, as a ‘phantom’. In

essence the link is critical because it provides a workflow input (e.g. product flow) but there are

no activities that ‘add value’ to the input so the process does not need to be modelled in any

detail. For example, in the BeerCo case, picking and packing will not have an impact upon model

behaviour because the product is not transformed in any way between actors but the product

flows through these activities. Although this decision concerns what to include, it is necessary to

include the interconnection but not to model any practices in any detail as they are not significant

(considered in next phase when the practices to be modelled are detailed).

The rules were useful when deciding what to include, or exclude, and the step also recognised the

importance of documenting the rationale for the decision made. It was useful when a link was

deemed to have a sufficient impact on model behaviour that it was considered in light of whether

it could be simplified. This was important as it was observed that the inputs that could be

simplified made up the boundary of the model, which has not been discussed in the literature

before. A simplified input is one that can be fixed (e.g. lead times in both cases) or can be

generated by a simple distribution (e.g. end customer demand in both cases); there are no further

inputs to consider. Additionally, another key problem that was addressed was the process of

formulating when the model boundary ends. This was achieved once all inputs had been

considered in the model boundary (inputs had been simplified, excluded or needed to be tested)

and there were no more ‘promoted’ process elements to trigger the need to return to phase four.

The test feature (for decisions that were ‘unsure’) was not used in either of the cases but it could

be observed that this decision is beneficial when formulating the model boundary at the

conceptual modelling stage. At the conceptual modelling stage it can be used to pinpoint the

components of the model that should be analysed using a prototyping method, by building a

simple computer model and providing insights into the key variables and interconnections in

order to design the conceptual model (Robinson, 2004a; 2004b). It, therefore, provides some

useful insights so that a decision can be reached at the stage of formulating the model boundary.

163

The ‘unsure’ decision was made in earlier refinements but it was concluded that this was down to

earlier attempts at designing the decision process. All the ‘unsure’ decisions could be discounted

at the end of the process. At this point there is a need to gain information from SMEs, the

question a modeller would need to address is: what information is required? It could be observed

that the domain knowledge provided from SCOR coupled with the process could facilitate the

decision-process and provide information that will aid the modeller to identify the information

required. Although in most cases the information provided by SCOR was sufficient to be able to

make a decision (e.g. descriptions were provided about each input). When performing a check of

the linkages in step 5.4 it was apparent that the candidate process elements were needed. In this

respect, the process of learning, through considering and reviewing the linkages, increased the

understanding of the model requirements, or it indicated a part of the model that should be a

priority for communicating with the client. Figure 7.12 shows how the information was displayed

and decisions reached with justification.

Figure 7.12 Extract of phase five from the BeerCo development case for the Wholesaler

7.3.5.3 Step 5.3: Repeat phase four and five for each PROMOTED process elements

Each promoted process element was added to the list of model inputs and candidate process

elements. This initiated step 5.1 – 3 until no process elements could be considered. During the

process, it was observed that towards the end of the step, the modeller would notice that the

majority of candidates have already been included in the model. Alternatively, they have been

simplified so no inputs need to be considered, thus indicating the process had been completed.

164

7.3.5.4 Step 5.4: Check the linkages between processes and inputs in the model

A step was added to check that the linkages between the processes and inputs included in the

model are ‘sufficient’ and ‘correct’ before proceeding. For example, the links between core

process elements included in the model and the processes and inputs that have been included

from the supply setting. It is important to note that the model up until this point has been

formulated by considering each interconnection (addressing the principle ‘start small and add’)

and whether it should be included based upon two rules.

The problem identified in the previous step was that the decisions reached on each

interconnection were subjective. To improve decision-making, information was gathered from

SCOR descriptions and SMEs when necessary. It does not satisfy the requirement that sufficient

and correct links exist between each improvement that could achieve each objective and those in

the supply setting.

To facilitate this problem a matrix was drawn up that listed each of the actors in the supply

system and the processes included for each actor (illustrated in figure 7.13). This was deemed

useful as it visually represented all the core, promoted and simplified inputs. It was used to check

the two different types of interconnections in the following two ways:

1. For each improvement that could achieve each objective. Trace the inputs from

processes that provide data sources to drive the calculation for each objective to the

point that a sufficient and correct link is made with the processes that represent an

improvement. Use the matrix to tick off each process that provides a link.

2. Any remaining ‘isolated’ processes and simplified inputs should be checked using the

justifications provided to verify that they are necessary as they affect model behaviour by

having a significant impact upon the objectives of study.

165

Figure 7.13 Template used to check the linkages between processes in the CarCo development case

This procedure was used successfully in both development cases. The matrix was used as a

reference point and a way to highlight each process as the check was being completed. For both

development cases there were sufficient links between the improvements and objectives.

In the CarCo development case the improvement is implemented in P2 (plan source) in the LA and

in P4 in the tier three suppliers (T and CHR). The change brought about by this improvement

impacts upon the behaviour of the supply system and is ultimately measured at S1.2 (receive

product) in the LA. Each of the included ‘promoted’ processes and ‘simplified’ inputs can be

checked along with the justifications stated for each decision to check that it should be included.

Using an Excel spreadsheet (shown in figure 7.14) this could be completed using the filtering

functions, selecting the included processes and each interconnection and ticking the matrix when

required. In this way all the different routes could be checked so that the justifications could be

checked. This also included some ‘dead-ends’, which were necessary such as planning orders,

deliveries and production. Additionally the manufacturing processes were included in both T and

CHR as they produced tracks and central head-rests which are both components of the seat set.

166

Start at S1.2 LA

D1.13 SS to S1.2 LA

D1.12 SS to D1.13 SS

D1.11 SS to D1.10 SS

D1.10 SS to D1.9 SS

Figure 7.14 Tracing back the inputs of included processes from a data source

7.3.6 Phase 6: Design of the detail of the model

Phase six implements two key concepts identified in the outline design:

The detail that needs to be included can be identified from the actual practices for each

process element included and simplified in the model

Modelling practice should represent the complexity and detail of the actual practice to be

evaluated

The aim is to firstly provide a detailed representation of the supply problem to be modelled (the

domain-orientated model). From this describe the requirements of the model in terms of how the

supply problem will be represented by the components in the computer model (the design-

orientated model). The phase is entered when the list of processes and inputs to be included in

the model have been checked. Information provided to the phase firstly is extracted from the

SCOR model to identify typical practices for each process element included in the model boundary

and the actual practice adopted for each process is identified from consultations with SMEs.

167

Table 7.15 Detailed steps for phase 6 of the SCM2

Phase 6: Determine and design the level of detail for each process element and input included in the model

Process steps Information required Information provided

Point of entry: From phase 5: Enter phase six when the list of processes and inputs to be included in the model specified by actor have been checked

6.1

Describe how each process element is actually implemented in practice, in sufficient detail of how the inputs (and sources) are converted to produce an output (to a destination), specified by each actor

6.1.1 List the process elements within the boundary of the model, by status and actor

Use the list presented in phase five

List of process elements specified by status for each actor

6.1.2 Identify ‘phantom’ process elements by determining the process elements that contain only a workflow input and no practices can be identified that would influence the characteristics of the workflow

Use the list from phase five to identify the inputs to each process element; Verify if necessary with the client

List of process elements that are to be treated as ‘phantoms’

6.1.3 Describe actual practice for the existing ‘AS-IS’ and ‘TO-BE’ supply system for ‘core’ and ‘promoted’ process elements

Use SCOR v.9 process element descriptions (SCOR v.9, section 3) to identify practices from the list of candidates, as a guide to aid in the collection of information from the client

List of descriptions of actual practice for each included ‘AS-IS’ and ‘TO-BE’ process element

6.1.4 Consolidate the list of actual practices, removing any duplications

Use the list from 6.1.3 Consolidated list of actual practices

6.2

Describe how each actual practice, specified by each actor, will be represented by the components in the computer model

6.2.1 Describe what processes, activities or events need to be included in the computer model to represent each actual practice

Use descriptions consolidated in 6.1.4.

Description of the processes, activities or events to be included in the computer model

6.2.2 Describe what entities need to be included to represent the activities or events in the computer model?

Use the descriptions from 6.2.1

Description of the entities to be included in the computer model

6.2.3 Describe any assumptions or simplifications incorporated into the description of the model to be developed (e.g. aggregation of model components, reduce the rule set)

Refinement of 6.2.1 and 6.2.2.

Description of any assumptions or simplifications incorporated into the description of the components in the computer model

Point of exit: To phase 7: Proceed when the components in the computer model represent all actual practices

Output: Description of how the components in the computer model and their relationships will represent the actual practices to be modelled

7.3.6.1 Step 6.1: Describe how each process element is actually implemented in practice

The aim of step 6.1 is to describe how each process element included in the model boundary is

actually implemented in practice (components that describe the domain). The previous analysis

had used the SCOR model to identify the processes, inputs to each process and the relationships

between the processes included in the model. The information that is missing includes the actual

practices that are implemented within each process.

In sub-step 6.1.1 the previous analysis provides the background information. This could be listed

with no problem for both cases. The table that lists each actor and the status of how a process is

treated was a useful means of extracting the information easily. Alternatively, it could be listed

directly from the output from phase five.

168

Sub-step 6.1.2 identifies the ‘phantoms’ which are, effectively, processes that have been included

because they provide a link that have a significant impact upon the behaviour of the model. It

was observed that this creates unnecessary detail that could be excluded. Effectively it is the

input that is required but no practices exist, or, a practice exists that will not have a significant

effect on the model accuracy. A process can be viewed using the previous model boundary list to

identify processes that have only workflow inputs. The justification should also provide some

guidance. In an Excel spreadsheet the filters can be used to select each process specified by each

actor and see which inputs have been included. A list of ‘phantoms’ is shown for the CarCo

development case, with an example of identifying the necessary information for D1.10 SS in figure

7.15.

Figure 7.15 ‘Phantoms’ in the CarCo development case (inputs shown for D1.10 SS)

Sub-step 6.1.3 is the main step in step 6.1 as it describes the actual practice for the ‘AS-IS’ and

‘TO-BE’ model. The ‘core’ process elements could be considered first as it is likely that they may

contain the greatest level of detail followed by those that were promoted and then the simplified

inputs can be described in terms of either being a fixed input or simple distribution. A column

was added so that the ‘AS-IS’ and ‘TO-BE’ descriptions can be described. The ‘TO-BE’ changes

should be within the ‘core’ process elements that describe the improvement as they are the

components that are implementing the change that is being evaluated. It was important to

include in the descriptions the actor that implements the practice and the relationships between

them. This makes it easier to describe the model components in the next step. In the case of the

BeerCo case, an extract is shown in figure 7.16. The SCOR descriptions of processes could be used

to identify practices and if no specific practice could be identified the description was useful when

169

describing the actual practice. For instance, three examples are highlighted where SCOR

descriptions were helpful:

1. S1.1 (schedule product deliveries) at the end customer – The model needs to be able to

generate a simplified input of the customer placing an actual order

2. S1.4 (transfer product) at the distributor – The model needs to be able to represent beer

being received from the factory and being stocked at the distributor goods receiving

location

3. M1.3 (produce and test) at the manufacturer – The model needs to be able to represent

the factory manufacturing beer

Figure 7.16 Extract of actual practice descriptions in the BeerCo development case

Sub-step 6.1.4 recognises that an actual business practice can be implemented in one or more

processes. The model components are described from the actual practices and not from the

SCOR descriptions as these were only used as a means to identify the structure, content and

relationships in the model. This ensures that the descriptions reflect the real world nature of the

problem. If an actual practice is implemented in more than one process then these can be

consolidated to produce a simpler list of the actual practices to be represented in the computer

model. This must not be confused with grouping of entities as this is a way of representing a

group item in a simulation model. An illustration is shown in figure 7.17 of the CHR CarCo

processes M1.5 (stage product), M1.6 (release product to deliver), D1.3 (reserve inventory and

determine delivery date), D1.4 (consolidate orders) and D1.5 (build loads) that are implemented

by a kanban practice which controls the movement of central head-rests.

170

Figure 7.17 Extract of how actual practices can be ‘consolidated’ for the CarCo development case

7.3.6.2 Step 6.2: Describe how the actual practices will be represented by the

components in the model

Step 6.2 uses the reduced list of actual practices to describe how each actual practice, specified by

the corresponding actor, will be represented by the components in the computer model. This key

concept is well documented in the literature in particular simulation texts (e.g. Pidd, 2004a;

Robinson, 2004a; 2004b) and, therefore, it is not implemented any differently than in existing

modelling practice. The only difference is that the actual practices have been derived by applying

a structured methodology that utilises the domain knowledge from SCOR.

Within different worldviews or even simulation approaches the terminology used to describe the

components in a model may vary (C.f. section 2.4.3). The objective in this step is to be generic so

that different terminology can be applied. Pidd (2004a) discussed the standard terminology for

DES using some labels that could be used generically: objects that constitute a system to be

simulated and the operations in which these objects engage over time. It was observed that it

was straight-forward to be able to describe each actual practice in terms of the activities or events

that are needed to be implemented in the model to represent them. This is asked first followed

by a description of how the activities/events can be represented in the model. Table 7.16

illustrates how these questions have been addressed in the BeerCo development case along with

a standard definition for the model component and examples of them.

171

Table 7.16 Model components, definitions and examples (in the BeerCo development case)

The final step is to incorporate any assumptions or simplifications into the description of the

model components. There are many standard discussions on how this can be achieved (c.f. in

section 4.1.2). Interestingly the methodology has used a number of simplification methods or

principles throughout the procedure (e.g. in the model boundary setting: excluding components

and details in the formulation of the model boundary, replacing components with random

variables or fixed inputs). A key method of simplification that has not been used but is useful and

is specific to simplifying model components includes removing components and interconnections

that have little effect on model accuracy (e.g. aggregating model components using represent a

section of an operation as a time delay and/or grouping entities). Another simplification that can

be used to minimise the detail in a model includes reducing the rule set (e.g. routes, schedules,

allocation of resources) which is described in detail in Robinson (2004b, pg. 90).

An example of five actual practices that were described in the BeerCo development case and how

they have been converted into the model components is shown in appendix D. These are

described using DES terminology, identifying the entities or resources that constitute the system

and how they engage in time (process, activities or actions). The entities are described by actor

and object (actor_object) and described in terms of the attributes that are required by the

process, activity or action (actor_object.attribute) e.g.

‘Retailer_order: An order from the retailer for units of beer (Retailer_order.qty) for a given date (Retailer_order.date)’ ‘Wholesaler_Warehouse: The units of beer available in Wholesaler warehouse (Wholesaler_Warehouse.AVAILinv)’

Questions asked in step 6.2 Model

Components Definition BeerCo case examples

What activities or events need to be implemented in the model to represent the actual practice?

Process A sequence of events in the chronological order in which they occur (Pidd, 2004a; 2004b)

Reserve inventory and determine delivery date, plan order, plan deliveries, schedule deliveries

Activity An operation over a duration of time of finite length that causes change in the system state (Tanir and Sevinc, 1994).

Receive product, ship product

Event

An occurrence of an operation at an isolated point in time; it may change the system state (Tanir and Sevinc, 1994). It initiates the beginning and ending of an activity or delay (Banks, 1999).

Product arrives at warehouse, customer place order, initiate sourcing plan cycle

How will the activities/events be represented in the model?

Entity Individual elements of the system that are being simulated and whose behaviour is being explicitly tracked (Pidd, 2004a; 2004b)

Warehouse, orders, vehicle, delivery schedule

Resources

Individual elements of the system that are not modelled individually, instead, they are tracked as countable items whose individual behaviour is not tracked by the simulation (Pidd, 2004a; 2004b)

Number of units of beer available in warehouse, number of units of beer on vehicle

172

The process, activities and events are described in sufficient detail so that they can be developed

into a computer model e.g.

‘Retailer player makes a decision on how much to order from the wholesaler in the next period using available planning data. A purchase order is created (Retailer_order) with the order qty (Retailer_Order.qty) and date (Retailer_Order.date) set on the retailer purchase order’ ‘Check to see if any backorders remain (Wholesaler_backorder>0) and create Wholesaler_onorder. It is calculated: Wholesaler_onorder = Retailer_order.qty + Wholesaler_backorder’

Simplifications and assumptions are included in the model and documented with the description

of the model components e.g.:

‘Include order acceptance rule based on order max size in place order’ ‘All orders received are accepted; Orders are received in each one week period; The order is delayed by 1 week’

7.3.7 Phase 7: Validate and document the conceptual model

Phase seven is the final phase of the methodology implementing one key concept:

The conceptual model is documented and validated

The aim of the final phase is to document and validate a conceptual model from the information

provided from the key outputs in the methodology. The phase recognises that the conceptual

modelling process is iterative (Robinson, 2004b) due to new insights or learning that occurred

during the process. For these reasons it is necessary to ensure that each of the descriptions

provided from phases or steps in the methodology are ‘correct’. This may result in any necessary

alterations when the validation check has not been satisfied. To improve the validity and

credibility of the conceptual modelling being developed ‘checks’ have been implemented at

certain points within the methodology. This phase implements a final set of checks on the draft

conceptual model.

The phase is entered after phase six has been completed but each of the steps involves gathering

descriptions from specific phases in the methodology. The phase has many points of exit when

issues have been identified warranting a need to return to a previous phase or step. When there

are no further revisions or alterations necessary to the draft description of the simulation model

173

to be developed the conceptual modelling process is complete. The descriptions contribute to

drafting the conceptual model to be developed in terms of Robinson’s (2004b) definition, within

in the context of SCM applications. These include:

Purpose of the model - Draft a description of the supply problem from the client’s

perspective (from phase 1)

Inputs - Draft a description of how each process is to provide data used to calculate each

objective (from phase 2)

Outputs - Draft a description of how the processes represent each improvement (from

phase 3)

Content - Draft a description of how the components and their relationships in the

computer model will represent each actual practice to be modelled (from phase 6)

Assumptions and simplifications - Draft a description of the assumptions and

simplifications that have been incorporated into the model components and relationships

(from phase 6)

174

Table 7.17 Detailed steps for phase 7 of the SCM2

Phase 7: Validate and document the conceptual model

Process steps Information

required Information

provided

Point of entry: From phase 6: Enter phase seven when the components in the computer model and their relationships will represent the actual practices to be modelled have been described

7.1

Draft the conceptual model by describing the computer model to be developed

7.1.1 Draft a description of the supply problem from the client’s perspective

From phase 1

A draft non-software specific description of the simulation model to be developed

7.1.2 Draft a description of how each process is to provide data used to calculate each objective

From phase 2

7.1.3 Draft a description of how the processes represent each improvement

From phase 3

7.1.4 Draft a description of how the components and their relationships in the computer model will represent each actual practice to be modelled

From phase 6

7.1.5 Draft a description of the assumptions and simplifications that have been incorporated into the model components and relationships

From phase 6

7.2

Validate the ‘correctness’ of the draft descriptions of the simulation model to be developed. If any issues arise then revision and adjustments are required by returning to a previous phase or step.

7.2.1 Check the description provided from step 7.1.1 by repeating step 1.5; If not correct return to the beginning of phase 1.

From 7.1.1

List of issues that need to be resolved by returning to a previous phase or step (only if necessary)

7.2.2 Check the description provided from step 7.1.2 by repeating step 2.4; if not correct return to the beginning of phase 2

From 7.1.2

7.2.3 Check the description provided in 7.1.3 by repeating step 2.4; if not correct return to the beginning of phase 3

From 7.1.3

7.2.4 Check the correctness of the descriptions provided in step 7.1.4 by asking SMEs the following question (e.g. circulate the draft description for feedback and/or provide a structured walkthrough of the actual practices and relationships in the model): Does the description of the actual practices and relationships in the model provide all the necessary details to be sufficiently accurate to evaluate the means by which each improvement is to achieve each objective. if not correct return to the beginning of step 6.1

From 7.1.4; Description of how each improvement is to achieve each objective described in 1.4; Consult SMEs on each description

7.2.5a Check the correctness of the descriptions provided in step 7.1.4 by examining each of the connections between model components, to determine whether the conceptual model reproduces the actual practices and relationships? If not correct then return to step 6.2

From 7.1.4

7.2.5b If necessary, to support the analysis in 7.2.4: Represent the components and relationships using a graphical means of representation (e.g. process flow diagram, logic flow diagram, activity cycle diagram).

See above

7.2.6 Check the draft description of each of the assumptions and simplification that have been incorporated into the model components and interconnections described in 7.1.4 with the client for the level of confidence that can be placed in them and their likely impact on the accuracy of the model; If not correct then return to step 6.2.3

From 7.1.4; Consult SMEs

7.3 Document the final non-specific description of the simulation model to be developed From 7.1 and 7.2

A final non-software specific description of the simulation model to be developed

Point of exit: To Phase 1, phase 2, phase 3, step 6.1, step 6.2: Re-enter a previous phase or step if any issues arise that need to be resolved Terminate conceptual modelling stage of a simulation project: Exit when the final description of the simulation model to be developed has been fully validated.

Output: A non-software specific description of the simulation model to be developed

There were fourteen observations made when refining and implementing the key concept into

phase 7, which are shown in table A.7 in appendix A. These observations were incorporated into

the phase shown in detail in table 7.17. As previously noted this step has incorporated existing

175

simulation practice aligned to the outputs from the necessary phases and steps in the

methodology. The main observations were that a draft description could be obtained from the

various different phases and steps in the methodology but these needs to be validated in full, in

case any new insights or learning’s have changed the nature of the conceptual model to be

created. The checks incorporated were to repeat some checks relating to defining the supply

problem, objectives and improvement. If the description is no longer correct then this means the

participants must return to the beginning of the associate phase and proceed through the

methodology. In addition three outstanding descriptions have yet to be validated:

Actual practices and their relationships between them provide all the necessary details to

be sufficiently accurate to evaluate the means by which each improvement is to achieve

each objective (addressed in step 7.2.4)

Model components and their connections between them reproduce the actual practices

and their relationships (addressed in step 7.2.5a and 7.2.5b)

The client and the modeller has a level of confidence in the assumptions and

simplifications that have been incorporated into the model components and

interconnections and their likely impact on the accuracy of the model (addressed in step

7.2.6)

The final validation procedure makes a useful distinction between validating the actual practices

and their relationships (a domain-orientated model) and how they are represented by the model

components and connections (a design-orientated model). The domain-orientated model had

been previously checked when the model boundary was formulated to ensure that there were

sufficient and correct links between business processes in the model. However, in the design of

the conceptual model the processes and inputs identified were described by the actual practices

to be implemented at the required level of detail. These descriptions had not been checked to

ensure that they were significantly accurate from the perspective of the client (credibility

requirement). Therefore, a step is added to check that the descriptions of the actual practices

with SMEs (e.g. circulate the description for feedback or provide a structured walkthrough of the

model) contain all the necessary details to evaluate the means by which each improvement is to

achieve each objective (information provided from step 1.4).

Two checks are included in the methodology to check the validity of the model components and

connections (design-orientated model) and the assumptions and simplifications that have been

incorporated into them. A previous discussion considered the need for a ‘hypothesis test’, to

determine whether the connections between the model components reproduce the actual

176

practices and relationships (C.f. section 4.4). This check was broken down into two sub-steps

because it was observed that it is difficult to validate the descriptions presented in a component

list. It would be easier to show the model components and interconnections if they were shown

using a graphical means of representation (e.g. process flow diagram, logic flow diagram, activity

cycle diagram). This is helpful because they graphically show the connections between the

processes and activities and the rest of the model and entities are shown to flow through

processes and activities. A further check is included for the assumptions and simplifications using

(Robinson, 2004b, pg. 215) guidance, the ‘assumptions and simplifications can be checked

between the modeller and the client for the level of confidence that can be placed in them and

their likely impact on the accuracy of the model’.

Appendix D shows the five actual practices for the BeerCo case, the way in which they were

represented by the components in the model including how assumptions and simplifications have

been incorporated into the model. These are further represented in a process flow diagram

presented in appendix E. Taking the practice that the retailer ‘places an order’ it can be seen that

this is implemented by five activities that ensure that the order size is not exceeded. Therefore,

the necessary details are that an order is placed per decision period and checked that an order is

within the max order size, (i.e. If no, the order is rejected, if yes, the order is accepted). Accepted

orders are sent to the wholesaler ‘receive order’ process. The graphical representation in

appendix E is useful as it shows that if an order is rejected then the human player is informed to

re-enter the order, and, if accepted, it needs to be sent to the wholesaler ‘receive order’ process.

The simplifications and assumptions detail that the orders are placed in each weekly decision

period and that orders must be within the maximum order size.

When all the validation checks are complete, there are no further issues to resolve by returning to

previous phases or steps indicating that the model is valid and credible. It is valid because the

accuracy of the model has been checked from the perspective of the modeller, most importantly

that the model components and connections reproduce the actual practices and relationships. It

is credible because the actual practices and relationships have been checked to ensure all the

necessary details are included to address how each improvement is to meet each objective.

There is also a greater level of confidence (from both the client and modeller perspective) in the

simplifications and assumptions incorporated into the model in relation to their likely impact

upon model accuracy. At this point, the final description of the simulation model to be developed

can be documented.

177

7.4 Implementing the SCM2 using a spreadsheet application The methodology can be implemented using a spreadsheet application (e.g. Microsoft excel

workbooks), which provide a number of advantages. Each of the outputs from the phases can be

reported in workbooks, within one spreadsheet. Both the detailed design cases were

implemented using Microsoft Excel workbooks along with any associated documentation (e.g. list

of SCOR process elements, inputs and sources).

There were three key advantages for using a spreadsheet application: its functionality, the way in

which data can be presented and the centrality of keeping all outputs in one document. Initial

designs of the output from each phase were presented in word-processing tables (e.g. Microsoft

Word). This proved cumbersome for the reason that the level of detail and number of entries

made using the word-processing tables were inappropriate. It was also difficult to re-use data

that was required for a future phase.

The functionality of a spreadsheet application enabled filters to be used, to sort data based upon

a set criteria (e.g. all promoted process elements at the factory, all process elements to be

tested). These features were used, to filter the necessary data, which would be inputted to a

subsequent stage. In particular during the designing of actual practice, filters could be used to

show common practices which could be aggregated. This was seen most notably in the CarCo

problem, where a kanban control system was used, for both the production and deliveries

between the tier three suppliers, third-party logistics provider and the seat supplier. Conditional

formatting was used to indicate the status of a particular data entry to distinguish it from another.

This was useful as it increased the readability of the document by displaying data clearly using

different colours for filled cells (e.g. promoted process elements indicated as green, red for

excluded). The functionality in a spreadsheet application also presents an opportunity to

automate some steps and reduce the time-consuming activities (this is considered in more detail

in section 8.6).

7.5 Alignment of detailed design of the SCM2 against specification

The detail design can be aligned against the specification to ensure it meets the requirements.

The requirements were identified in chapter five, when the specification for the methodology was

formed. These included the requirements for an effective conceptual model, a good

methodology and for conceptual modelling of supply chain problems. Each of these requirements

is considered in turn, reviewing the content of the methodology to demonstrate that the

specification has been met.

178

7.5.1 Meet the requirements for an ‘effective’ conceptual model

The SCM2 meets the requirements for an effective conceptual model. It has been developed on a

fundamental principle that the model should be kept as simple as possible and that it should

create a valid and credible conceptual model. Table 7.18 shows how the requirements for an

effective conceptual model have been realised in the SCM2.

Table 7.18 Aligning the SCM2 to meet the requirements for an ‘effective’ model

Requirement Realised in the SCM2

Keep the model as

simple as possible

The ‘core’ processes that represent the improvements and provide data values for objectives (in phase 2 and 3) are identified. The model boundary is initiated from a list of ‘core’ processes (in phase 4)

The model boundary identifies the critical interconnections between the ‘core’ processes and those in the supply setting (those processes that have been included in the model by being ‘promoted’) (in phase 5)

The boundary of the model included the inputs that have been simplified; they have no further inputs that could be considered.

The level of detail required in the description of the model components is determined from the actual practice described (in phase 6). The actual practices have been described with guidance using SCOR which suggests a level of process decomposition.

Methods of simplification are included in the process and not just as a final stage (e.g. excluding components and details, in step 5.2.4; replacing components with random variables or fixed inputs, in step 5.2.1)

Assumptions and simplifications are incorporated into the description of model components and their connections (in step 6.2)

Assumptions and simplifications are validated in the final phase (step 7.2) with the client and modeller to ensure that there is a level of confidence and that they do significantly impact upon model accuracy

Build valid and

credible models

The problem is formulated precisely in phase 1 and the objective and improvement is detailed (in phase 2 and 3). Two checks are incorporated into phase 1 to ensure that the description of the supply problem is ‘correct’

The participants in the process of conceptual modelling are included to ensure that there is interaction on a regular basis (in steps 1.1 – 1.5; 2.4; 3.3; 5.2; 6.1; 7.2)

SMEs are consulted (in steps 5.2; 6.1; 7.2)

A step in the final validation asks SMEs whether the descriptions of the actual practices and relationships in the model provide all the necessary details to be sufficiently accurate to evaluate the means by which each improvement is to achieve each objective (in step 7.2.4)

A step in the final validation examines the connections between model components, to determine whether the conceptual model reproduces the actual practices and relationships (in step 7.2.5)

A step in the final validation checks the assumptions and simplifications that have been incorporated into the model components and interconnections with the client for the level of confidence that can be placed in them and their likely impact on the accuracy of the model (in step 7.2.6)

Phases two and three describe the improvement and objectives so that a set of ‘core’ processes

that need to be included in the model are identified. This is in effect the foundations, the building

blocks to identify the simplest model. Each of the interconnections to ‘core’ processes is

considered in turn to identify candidates for inclusion. At the heart of the methodology is the

decision of how to treat candidates by either including, excluding or testing them (using a

prototyping method). This aids in identifying the model boundary using two rules, one that

provides guidance on how to include a process and a second that considers whether it could be

simplified (i.e. fixed input or sample distribution). Additionally the methodology embeds methods

of simplifications at the various points in which they can be implemented in a procedure for

conceptual modelling (e.g. excluding components and details in step 5.2.4) and not just at the

end.

179

The methodology addresses Law’s (2007) issues relating to building a valid and credible model at

the early stages of a simulation project. This entails formulating the problem precisely,

interacting with the decision-makers on a regular basis throughout the process of conceptual

modelling and to consult appropriate SMEs. The supply problem is described in detail using a

prescribed format and implements two checks before detailing the improvement and objective in

more detail. The client (or decision-makers) and SMEs are involved throughout the whole

conceptual modelling process but the methodology identifies the specific points in which they

need to be consulted. A significant advantage of the methodology is that it uses the SCOR model

to provide domain-knowledge to enable a more focused and efficient process, in particular when

information is required from the client and SMEs.

The methodology also includes checks for the key components that make up the description of

the conceptual model: supply problem, objectives and improvements. A method is also designed

to check that the processes and inputs included in the model boundary have ‘correct’ and

‘sufficient’ linkages between ‘core’ processes and those processes and inputs included from the

supply setting. A final validation procedure re-checks that the supply problem, objectives and

improvements are ‘correct’. The procedure recognises that the purpose of the model may change

due to a greater understanding of the problem being studied. In addition, check the descriptions

of the actual practice and relationships in the model provide all the necessary details to be

sufficiently accurate with the client and SMEs (credibility); examination of the connections

between model components to determine that they replicate actual practice and their

relationships (hypothesis validity); and that both the modeller and the client have confidence in

the assumptions and simplifications incorporated into model component descriptions for a

certain level of model accuracy (validity and credibility).

7.5.2 Meet the requirements of ‘good’ methodologies

The SCM2 meets the requirements of the desirable characteristics of a good methodology in the

context of conceptual modelling for SCM applications. This includes a procedure (or guide),

participation and points of entry. Table 7.19 shows how each of these requirements have been

realised in the SCM2.

180

Table 7.19 Meet the requirements of ‘good’ methodologies Requirement Realised in the SCM2

Meet the

requirements of good

methodologies

Provide a

procedure

Well defined stages to gather and analyse information from the client (in steps 1.1 – 1.5; 2.4; 3.3; 5.2; 6.1; 7.2), SMEs (in steps 5.2; 6.1; 7.2) and the SCOR model when necessary (in steps 1.1; 1.2; 1.4; 2.1 – 2.3; 3.1; 4.1; 5.2; 6.1)

Suggests a format and terminology for describing the supply problem (in phase 1); describing the objective (in phase 2); describing the improvement (in phase 3); describing the actual practices and relationships (in step 6.1); describing the components in the model and their connections (in step 6.2)

Represent the conceptual model in a component list (in step 6.1; 6.2 and 7.2); graphically represent the conceptual model using a graphical means (in step 7.2)

Provide a method to identify the connections between processes and extract information from SCOR (in phase 4)

Provide a method to formulate the model boundary (in phase 5)

Use an hypothesis validity test to examine the model components and connections (in phase 7.2)

Suggest consulting the client and SMEs in the validation process (e.g. circulate the description of the conceptual model, structured walkthrough) in step 7.2

Provide a written record to justify any decisions made when formulating the model boundary (in step 5.2) and simplifications and assumptions incorporated into the model components (in step 6.2)

Participation in

each step Participation between the modeller, the client and SMEs (see building a valid and

credible conceptual model)

Embed points

of entry

Point of entry to the conceptual modelling process clearly defined in phase 1

Points of entry embedded at the beginning of each phase, with the requirements that should have been met from a preceding phase/step

Iteration between steps is noted, particularly when formulating the model boundary in phase 5 and when completing each of the validation checks in phase 7.

Checks state that if the rule has not been met the point of return to a previous step (in steps 1.5; 2.4; 3.3; 5.4; 7.2).

The procedure laid down in each of the phases has well defined stages for gathering and analysing

information from four key sources: the client, SMEs, SCOR guide and from a previous step in the

methodology. SCOR is used not to replace interactions and consultations with the client and

SMEs but to improve the process. The methodology includes a number of established principles,

methods of simplification and means to represent the content of a conceptual model. Moreover

it offers specific guidance for tackling some of the most demanding and difficult aspects of

conceptual modelling such as formulating the problem correctly, gathering information from

clients, SMEs and SCOR, identifying the connections between the components in the model,

determining the model boundary and validating a conceptual model. These procedures are novel

and address specifically the needs of evaluating supply chain problems.

The involvement of participants is included in the description of the procedure, specifically how

information is obtained from them. The modeller is responsible for following the steps laid down

in the methodology and interacting with the participants as suggested in the description of each

step. The methodology does not consider (as suggested in Platts, 1994) how individuals in the

group achieve enthusiasm but some of the steps have been designed to provide clarity and

commitment between the modeller and the client (e.g. check the description of the supply

problem). There are also decisions that need to be reached, some present no difficulty at all (e.g.

181

identifying candidate processes) if using SCOR while one of the most challenging tasks of

conceptual modelling, identifying the model boundary is facilitated by decision rules, using SCOR,

interacting with SMEs when necessary and documenting the justification for the decision made.

The point of entry to the methodology is clearly defined in phase one and for each of the phases.

There are also places in the methodology that may require iteration to a previous step. In

particular when processes are promoted in the model boundary formulation this initiates the

need to return to phase four. Similarly the checks are in place to ensure the ‘correctness’ of the

descriptions used to create a conceptual model. If the requirements in the checks are not

satisfied then the points of entry in a previous step are stated.

7.5.3 Meet the requirements for conceptual modelling of supply chain problems

The SCM2 meets the requirements for conceptual modelling of supply chain problems. This

includes addressing the range of supply chain improvements, for a given objective within the

setting of the supply problem. Table 7.20 shows how the requirements for conceptual modelling

of supply chain problems have been realised in the SCM2.

Table 7.20 Meet the requirements for CM of supply chain problems Requirement Realised in the SCM2

Handle supply chain

improvements

Alternative supply chain improvements are described in terms of how and which actors are affected by change (in step 1.2). Information is obtained from the client and/or using SCOR best practice guide.

The detail of how each improvement is to be represented is described in phase 3. Information is obtained from SCOR to guide the description, particularly to obtain the processes that implement a particular business practice.

Address a range of supply chain

objectives

The objectives of study are described in terms of the impact on supply chain performance attributes that the improved supply system should achieve. Information is obtained from the client using SCOR performance attributes.

The detail of how each objective will be measured is determined in phase 2. The objectives are described using the SCOR hierarchy of supply chain performance measures at three different levels and its associated detail (e.g. calculation, data source)

Identify interconnections within

the supply setting

The nature of the supply setting is described (e.g. actors in the supply system that have a cause and effect relationship between the improvement and objective, and any important situational information (that may influence the scope of the problem) in step 1.3.

The interconnections between the inputs of included processes and their sources, are determined in phase 4, those that have yet to be considered are treated as ‘candidates’ for possible inclusion.

‘Candidate’ process elements are considered for inclusion in phase 5 based upon two decision rules.

The methodology uses information provided from SCOR which is ‘designed as a tool to describe,

measure and evaluate any supply-chain configuration’ (Lockamy and McCormack, 2004, pg. 1194)

and it can be used in simulation applications (Persson and Araldi, 2009). The benefits of using

SCOR have already been described (C.f. section 6.4), but can be summarised as:

182

SCOR describes plan, source, make, deliver and return processes at three levels of process

decomposition using standardised terminology (Meyr et al., 2002) and process orientated

language

SCOR includes an extensive database of supply chain practices and metrics (Persson and

Araldi, 2009) and describes the inputs, outputs and the basic flow of process elements at

the third level of decomposition

The first phase describes a supply problem using SCOR terminology and details the improvement

and objective in phases two and three. The steps clearly recognise that SCOR should only be used

as a guide. Situational information is also required from the client. The benefit of using SCOR in

this context is that it suggests the processes that need to be modelled for a given practice and

metric. The inputs and source processes are considered to formulate the model boundary using

the relationships described in SCOR between business processes.

7.6 Chapter summary

The chapter has presented an overview of the phases and steps to follow as laid down in the

SCM2. Two application cases were presented to detail and refine the SCM2 with rationale for their

selection. Each of the phases was considered in turn so that the key concepts described in

chapter six could be implemented. A range of principles and observations were considered and

incorporated into the design. Each of the steps described in the methodology were illustrated

using the development cases, justifying any of the decisions made.

The final part of the chapter demonstrated that the detailed and refined design of the SCM2

meets the required specification presented in chapter five. This includes:

Requirements for an effective conceptual model – The methodology aims to keep

the model as simple as possible, initiating the process with the ‘core’ processes and

formulating the model boundary by considering the interconnections between ‘core’

processes and the supply setting. The methodology also incorporates checks within

the phases to establish the ‘correctness’ of the descriptions provided and a final

validation procedure to redo key checks in the process and at the end review the

accuracy of the conceptual model from both the client’s (to show that the conceptual

model is credible) and modeller’s (to show that the conceptual model is valid)

perspectives.

Requirements for a good methodology – The methodology provides detailed steps

for gathering and analysing information from the client, SMEs and the domain-

183

knowledge extracted from SCOR. Methods are suggested for structuring a supply

problem, identifying the interconnections between processes, formulating the model

boundary, describing how the components in a model represent each actual practice

and for validating the conceptual model. Points of entry are embedded into the

phases of methodology, to ensure steps are completed successfully and to facilitate

iteration.

Requirements for conceptual modelling of supply chain problems – A supply chain

problem is described in terms of its objectives and improvements selected within a

supply setting. SCOR is used as an aid to describe improvements and metrics and

identify the interconnections between processes that should be included in the

model.

The following chapter applies the detailed and refined SCM2 to a preliminary validation case to

demonstrate that the methodology is initially feasible and has utility.

184

Chapter 8 Preliminary validation of the SCM2 (Stage V)

The chapter implements stage V of the research methodological programme and addresses the

third and final research objective. The primary aim is to preliminarily validate the methodology by

applying it to a validation case to demonstrate that it is both initially feasible and has utility. This

builds upon the previous chapter that has refined the methodology and aligned it so that it meets

the specification of requirements. The chapter is structured to fulfill the following five aims:

1. Presentation of the validation case (discussed in section 8.1) - The CoffeePotCo case is

described and justified

2. Apply the methodology to the validation case (discussed in section 8.2) - Walkthrough

each of the steps as prescribed in the methodology in full up to the point that the actual

practices to be represented in the computer model are described

3. Purpose of the evaluation the SCM2 (discussed in section 8.3) – The purpose and the

sub-criteria for the feasibility and utility is described

4. Evaluation of the initial feasibility of the SCM2 (discussed in section 8.4) - The

methodology is evaluated to demonstrate that it is initially feasible using the sub-criteria

identified in section 8.3

5. Evaluation of the initial utility of the SCM2 (discussed in section 8.5) – as above but in

relation to the utility sub-criteria

6. Discuss areas for further testing (discussed in section 8.6) – Issues for further refinement

and testing are identified. The discussion centres upon the need for further applications

with different facilitators and participants

7. Identify opportunities to improve the methodology (discussed in section 8.7) – Discusses

three key opportunities to automate parts of the process, strengthen the use of domain

knowledge in the process and develop a web-based tool.

8.1 Presentation of validation case: CoffeePotCO

The validation case is of a multi-national company (CoffeePotCo) that is addressing a difficult

decision, regarding where and how to cost effectively manufacture products in a global and

complex supply setting. The validation case is described in more detail in terms of its

improvement, objectives and supply setting, as the methodology is applied in section 8.2.

The advantage of using this case is that the computer model has been described and the findings

from the study published in Taylor et al., (2008). The researcher was involved in the study over a

two year period with three co-authors. It makes use of a scenario-based simulation approach that

utilises actual product data and information from the published literature. A discrete-event

185

simulation programme named ‘SIMNET II’ (See Taha, 1992 for details of the programme) was used

to evaluate the supply problem.

The validation case is representative and typical of a supply chain problem that has been

evaluated using a simulation approach. Taylor et al., (2008) highlight the significance and

implications to the practicing manager of the case by stating that the operational and strategic

implications of global sourcing have not been well researched (Hong and Holweg, 2005) except in

Lowson (2002). In the case of Lowson (2002) a quantitative approach was proposed to determine

sourcing costs; the study did not focus upon inventory needs for a desired service level. A review

by Goetschalckx, Vidal and Dogan, (2002) supports this finding when outlining the characteristics

of published strategic logistics models and a review of global supply chain design by Meixell and

Gargeya (2005), shows that none of the previous literature in the area considers the stochastic

customer service level.

The product used in the study was a coffee maker, which is ‘functional’ in nature. There has been

a great deal of product and process related information published in support of this product

selection in Ulrich and Pearson (1998). For the purpose of this evaluation two scenarios were

selected that examined an efficient manufacturing scenario in a low-cost area with either

shipments made in (1) small (by air), or (2) large quantities (by road and ship). The experimental

situation is shown in figure 8.1.

Figure 8.1 Graphical illustration of CoffeePotCo supply problem

8.2 Application of SCM2 to preliminary validation case

The SCM2 is applied in this section by following the prescribed procedure as laid down in the

methodology (presented and detailed in chapter seven). This was facilitated by the researcher to

ensure consistency in its application. The aim is to show that the methodology can be followed

186

up to the point of describing the actual practices to be represented in the computer model and

provide the necessary output. It was previously argued in the research programme chapter that it

is at this point that the methodology is novel and could be compared against a validated

computer model.

The output from each phase is documented in each section corresponding to applying each phase

of the methodology. The client role has been played by one of the expert modellers involved in

the design and the building of the computer model. This was particularly valuable when

completing the validation checks in the methodology.

8.2.1 Phase one: Describe the supply problem

The supply problem was described by following the four steps in phase one and the final step

checked the description for ‘correctness’. The objective of study, description of improvements to

change the existing supply system, description of the problem setting and statement of how each

improvement could achieve the desired impact of the objective(s) for the CoffeePotCo validation

case is summarised in table 8.1.

Table 8.1 Statement of the supply problem (CoffeePotCo) Statement of supply chain problem

Statement of objective(s) of study

Output from 1.1

A multi-national manufacturing company (MNC) is deciding how to cost effectively manufacture products in a global setting. The aim is to determine how much finished goods stock (reduce supply chain assets) to have on hand to support sales at a 95% desired service level (increase supply chain reliability).

Description of improvements to change the existing system

Output from 1.2

A MNC has an efficient manufacturing facility in a low-income/low-cost location (i.e. Asia or Africa) and a warehouse in a high-cost area where the product is primarily distributed and sold. Shipments are currently made in large quantities, with a cost effective and slow shipping method (road and sea). The MNC wants to consider the impact of a change in the shipping method, by shipping in small quantities, with an expensive and fast shipping method (all air) on the defined objective.

Description of the problem setting

Output from 1.3

The MNC has an efficient manufacturing facility in a low-income/low-cost location (i.e. Asia or Africa) and a warehouse in a high-income/high-cost location where the product is primarily distributed and sold (i.e. North America or Western Europe). The capacity for an efficient production facility is defined as one which has a low cost of capital and shipping in economic quantities. The method for shipments from a low-cost manufacturing location to a warehouse in a high-cost area can be larger, cost effective and slow, or small, expensive and fast. It is assumed that the product selected is a coffee maker (Mr Coffee Expert Model) which is representative of a functional product type.

Statement of how each improvement could achieve the desired impact on the objective(s)

Output from 1.4

An off-shore location offers advantages to reduce cost (e.g. Alguire, Frear and Metcalf, 1994; Fagan, 1991; Monczka and Trent, 1991). The study seeks to examine how much finished goods inventory at hand is needed in the warehouse to satisfy a defined customer service requirement at lowest cost. The shipment size, speed and cost will affect how much finished stock is available at hand. If there is insufficient inventory stock-out will occur leading to the service level not being met, while too much inventory will satisfy the requirement but will incur a cost. Simulation is a good method to evaluate this problem as it will allow a user to adjust the re-order point to obtain a desired service level and review the implications on finished goods inventory costs.

The objective of study can be described using the supply chain performance attributes (step 1.1).

The aim of the study is to determine how much finished goods stock to have on hand to support

187

sales at a 95% desired service level. This can be translated into SCOR performance attributes as a

‘reduction’ in ‘supply chain assets’ and ‘increase’ in ‘supply chain reliability’.

The improvement can be selected and described to achieve the objective of study (step 1.2). This

includes evaluating the most cost effective way to ship a product from a low-income/low-cost

location (i.e. Asia or Africa) to a warehouse in a high-income/high-cost location (i.e. Western

Europe or USA). The existing approach is to ship in large quantities, with a cost effective and slow

shipping method (road and sea). The alternative is to consider shipping in small quantities, with

an expensive and fast shipping method (all air).

The setting of the supply problem can be described in terms of the actors in the supply system to

be evaluated and product information (step 1.3). The scope of the evaluation is confined to one

product (Mr Coffee Expert Model as detailed in Ulrich and Pearson, 1998) which is representative

of a functional product type. The actors include the MNC that has an efficient manufacturing

facility in a low-income/low-cost location (i.e. Asia or Africa) and a warehouse in a high-

income/high-cost location where the product is primarily distributed and sold (i.e. North America

or Western Europe).

The means by which the improvement is to achieve the objective by bringing about change in the

desired supply system can be described (step 1.4), using published sources and confirmation with

the SME. It is clear from the literature that an off-shore location offers advantages to reduce cost

(e.g. Alguire et al., 1994; Fagan, 1991; Monczka and Trent, 1991). However, this question forces

the participants to consider how the shipment method (size, speed and cost) will have an impact

on any potential stock-outs or over-supply of finished goods. For instance, if there is insufficient

inventory stock-out will occur leading to the service level not being met. Alternatively, too much

inventory will satisfy the requirements but will incur higher costs. Simulation would be a good

method as it would allow a user to adjust the re-order point to obtain a desired service level and

record the implications on finished goods inventory costs. The output from phases steps 1.1 – 1.4

was deemed correct after consultation with the client (step 1.5).

8.2.2 Phase two: Determine how each objective is to be measured

The objective is described in terms of how it will be measured by following three steps and a final

validation check. A description of the supply chain performance measures for each objective,

how each performance metric will be calculated from the data sources that are used to drive the

calculation and nature of the measurement is summarised in table 8.2.

188

Table 8.2 Statement of each objective to be measured (CoffeePotCo) Statement of how each objective will be measured

Perf. Att. Perf.

metric level

Perf. metric Definition of metric calculation Process

elements Actor

M’ment span

Output from 2.1 Output from 2.2 Output from 2.3

Assets Level 3 metric

AM3.16: Inventory days of supply

(Value of finished goods inventory/(COGS/365)) S1.4 WH Process

D1.8 WH Process

Delivery reliability

Level 2 metric

RL.2.2: Delivery performance to customer commit date

The percentage of orders that are fulfilled on the customer's originally scheduled or committed date = [Total number of orders delivered on the original commitment date] / [Total number of orders delivered] X 100%

D1.3 WH Process

D1.12 WH Process

D1.13 WH Process

The supply chain performance metric is described using the hierarchy of metrics presented by

SCOR at three different levels. No level 1 (strategic) metrics were deemed appropriate for

evaluating the objective leading to a review of level 2 and 3 metrics for each performance

attribute (steps 2.1.2 – 2.1.3). The metric that best describes reducing supply chain assets by

minimising finished goods inventory is the ‘inventory days of supply’ (AM3.16) metric. Likewise

the ‘delivery performance to customer commit date’ metric was selected to improve the delivery

reliability performance attribute. In the case of the latter, some alternatives were available (e.g.

from the customer or suppliers perspective, documentation accuracy); the customer commit date

was selected because it is the warehouse that wants to track the delivery performance to the

customer to a specified date.

Once the metrics had been identified it was relatively straight-forward to extract from the SCOR

descriptions of performance metrics, how each metric is to be calculated from the data sources

that are used to drive the calculation. There was a difficulty obtaining the data sources from

SCOR to drive the ‘inventory days of supply’ metric. The SCOR documentation (SCC v.9, section

2.5.2) adequately defined how the metric should be calculated but suggested the data sources are

not specified as they can be obtained by importing data from an existing business system (e.g.

ledger account). This may suggest that the system may need to be included. However, by looking

at the definition the information can be obtained by calculating the value of finished goods stock

from inventory availability, multiplied by a holding cost. This information can be obtained from

S1.4 and D1.8 where ‘source’ and ‘deliver’ inventory availability information is calculated. SCOR

provides good information on the data sources for the ‘delivery performance to customer commit

date’ metric.

The third step of phase two (step 2.3) uses information provided by 2.1 to specify the actors (step

2.3.1) and the measurement span for each performance metric (step 2.3.2). This was deemed

important in the refinement of the methodology otherwise it would be difficult to perform the

189

proceeding analysis. In light of the supply problem, the delivery performance and inventory days

of supply is measured at the warehouse location. The descriptions provided from phase two were

checked for ‘correctness’ with the client before proceeding to phase three.

8.2.3 Phase three: Determine how each improvement is to be represented

The improvement is described in terms of how the processes will represent it by following two

steps and a final step to check the description for ‘correctness’. A description of the level of

process detail for each improvement specified by actor is shown in table 8.3.

Table 8.3 Statement of how each process represents each improvement (CoffeePotCo) Statement of how each process is to represent each improvement

Improvement option Level of process detail

Business process

Actor

Output from step 1.1.2 Output from step 3.1 Output

from 3.2

A MNC has an efficient manufacturing facility in a low-income/low-cost location (i.e. Asia or Africa) and a warehouse in a high-cost area where the product is primarily distributed and sold. Shipments are currently made in large quantities, with a cost effective and slow shipping method (road and sea). The MNC wants to consider the impact of a change in shipping method by shipping in small quantities, with an expensive and fast shipping method (all air) on the defined objective.

Level 3 D2.10 Fact.

Level 3 D2.11 Fact.

Level 3 D2.12 Fact.

Level 3 D2.13 Fact.

Unlike the development cases there were no specific practices suggested by SCOR to represent a

change in shipping method (e.g. small or large). This highlights a weakness in SCOR, however the

step was described in enough detail to use SCOR as a guide to define which processes would be

needed to represent the improvement. Firstly, the improvement is related to the ‘deliver’ process

(step 3.1.1) and secondly, to a ‘make-to-order’ environment (step 3.1.2). This means that the

focus of the evaluation is in the ‘D2: Deliver make-to-order product’ business process.

There are many transportation related practices in D2; one of these is ‘cross-docking’ that could

be reviewed for information. This is a warehousing strategy that involves the movement of

material directly from the receiving dock to the shipping down with the minimum in-storage time

(Apte and Viswanathan, 2000). Effectively the factory ships packaged finished goods via either a

seaport, or an airport. This docking area could be treated as a trans-shipment (order is received

already packaged for delivery to the customer, SCOR V.9, 2008). Using the information provided

by SCOR for this practice and verifying any decisions with the client led to the D2.10 – D2.13

process elements being identified (step 3.1.3). The rationale for this is that delivery times and

costs which include packing (D2.10), loading (D2.11), shipping to warehouse (D2.12) and receiving

the product at the warehouse (D2.13) will be influenced by shipment size (large or small) and

190

method (sea and road or by air). The practices are implemented at the factory location (via a

docking location) (step 3.2).

The descriptions provided from phase three were checked for ‘correctness’ with the SME before

proceeding to phase two. The methodology forced both the facilitator and the SME to clearly and

concisely consider the impact of the improvement on different processes before reaching

agreement between both parties. There were a number of changes to the original description; in

particular there was a debate about how the processes identified would be influenced by the

improvement.

8.2.4 Phase four: Determine the model inputs and source process elements

The model inputs and candidate process elements are determined by following two steps using

the domain knowledge provided by SCOR. Figure 8.2 shows that each core process element

defined in phase two and three were reviewed in turn by extracting, from the SCOR

documentation the input fed by the process element included in the model (step 4.1.2) and its

source (step 4.1.3). The step was detailed enough to emphasise the need to make explicit the

actor that implements each included process element and the actor which generates the input

from a source process element.

Figure 8.2 Interconnection identified for each process element in the model

The source process elements were discriminated against those process elements that currently

exist in the model. For example, the core processes D2.11, D2.12, D2.13 have workflows that are

already included (i.e. D2.10 is core as well as D2.12 and D2.13 having workflow connections) so

191

they no longer need to be considered for inclusion. Each of the process elements that have not

been considered are effectively ‘candidates’ for possible inclusion in phase five. Phase four is

repeated for each promoted improvement that had been determined in phase five until no

promoted process elements are left to consider. In this case 207 entries were made in the

analysis resulting in a host of candidate process elements being considered for the factory,

warehouse and customer.

8.2.5 Phase five: Formulate the model boundary

The model boundary is formulated by following three steps and a final check to be satisfied that

there are sufficient and correct links between processes and inputs included in the model. Figure

8.3 shows an illustration of the decisions made to include (simplify or promote), test or exclude an

input from a candidate process element by applying the two rules. The figure also shows that the

analysis and documentation (in particular a justification for each decision) was aided by using a

spreadsheet application.

Figure 8.3 Formulation of the model boundary (CoffeePotCo)

Applying the steps outlined in phase five takes seven rounds of iterations between phase five and

four, until no process elements and their source inputs are left to consider. The steps were

initiated by considering the source inputs from the core process elements that have not already

been included in the model. At each decision point the two rules were applied and justification

was recorded.

The decisions made about how to treat each candidate process element and input resulted in

many being simplified, promoted and excluded but none were deemed necessary to test. Table

192

8.4 shows those process elements that were included within the boundary of the model. At this

point it must be noted that some of the process elements and associated inputs were treated as

‘phantoms’ in phase six, as they are only included because they provide a necessary workflow, but

the practice itself adds no significant value (i.e. the link is critical but the activity is not).

Table 8.4 Promoted process elements and simplified inputs (CoffeePotCo) Inputs and source process element that were promoted Simplified inputs

Customer N/A (Customer) Customer Replenish Signal; (Customer) Customer Order

Warehouse

Receipt Verification (S1.2, S1.3); Scheduled Receipts (S1.1); Delivery Plan (P4); Sourcing Plans (P2); Validated Order (D1.2); Scheduled Receipts (S1.1); Planning Data (EP.3); Order Backlog (D1.11); Load Information (D1.5); Finish Goods Inventory Target Levels (ED.4); Product On Order (S1.1); Packed product (D1.10); Daily Shipment Volume (D1.4); Picked product (D1.9); Shipment Routes (D1.6, D1.7)

Product Inventory Location, Finished Goods Inventory Location; Service Levels; Product Inventory Target Levels; Order Rules

Factory Picked product (D2.9); Production Schedule (M2.1); Finished Product Release (M2.6); Information Feedback (M2.1 – 6); Order Signal (D2.3); Delivery Plans (P4); Load Information (D2.5); Booked Order (D2.2); Consolidated Orders (D2.4

Shipping Parameters and Documentation (ED.6); Inventory Availability (M2.2); DC/Vendor Transit Time (N/A)

There were a few process elements for the factory, warehouse and customer that could be

simplified (step 5.2.1). At the customer location this included the demand which is generated by

a simple distribution. The warehouse includes the inventory locations, target levels, service levels

and order rules which are fixed. In the case of the factory simplified inputs include the shipping

parameters; inventory is assumed to be infinite to satisfy production and the shipping time is

fixed.

The customer had no promoted process elements but many were added for the warehouse and

factory. The warehouse included demand and order information, planning of how much product

to deliver the customer and order from the factory, managing inventory, shipment quantities and

routes and necessary product flows. The factory included order information, planning and

material flows similar to the warehouse but also included processes for manufacturing. The

process elements that generate these sources were promoted as the inputs they generate will

affect model behaviour by significantly impacting on the objectives of study and cannot be

simplified. Table 8.5 demonstrates the number of iterations between phase five and six when a

candidate process element had been promoted in step 5.2.2.

193

Table 8.5 Candidate process elements promoted in each round (CoffeePotCo) Number of iterations between phase

five and six

Candidates process elements promoted in step 5.2.2

Factory Warehouse Customer

Initiated with core process elements D2.10, D2.11, D2.12, D2.13

S1.4, D1.8, D1.3, D1.12, D1.13

N/A

Iterative round 1 D2.9

S1.2, S1.3, S1.1, P4, P2, D1.2, D1.11 None

identified

(S1.1 – simplified)

Iterative round 2 M2.1, M2.6, D2.7, D2.8 D1.5, ED.4

Iterative round 3 P3, M2.3, M2.4, M2.5, D2.6 D1.4, D1.10

Iterative round 4 D2.3, P4 D1.9

Iterative round 5 D2.3, D2.5, D2.4 D1.7

Iterative round 6 D2.2 D1.6

A vast amount of entries were excluded from the model as they were deemed to not have an

impact on the model behaviour (step 5.2.4). For instance, the warehouse does not manufacturer

any products and no returns are assumed. Similarly, it is not necessary to include the sourcing

process at the factory as the improvement specifically looks at the impact of the shipping method

on the warehouse delivery performance to the customer. Another example includes some of the

planning processes, in particular there is no supply chain planning taking place between the

customer, warehouse and factory.

The output from the phase is presented in a simple table (shown in figure 8.4 – note the

phantoms are considered in phase six) listing SCOR process elements highlighted by their

boundary status (core, promoted or simplified) for the factory, warehouse and customer (step

5.4). This table was used to verify that all core process elements that represent the improvement

will have an impact upon the metric. It was useful to walk through the process starting from each

metric and working back through the process elements with consultation with the client. There

were no issues of concern; all the critical links were included.

194

Figure 8.4 Promoted, core and simplified process elements (CoffeePotCo)

8.2.6 Phase six: Designing the model detail

The level of detail for each process element and input to be included in the model is determined

and designed by following two steps. The preliminary validation only applies to the first step that

lists the actual practices to be represented in the computer model (step 6.1). The description of

the actual practices are listed, and described in appendix G, which are used to compare with the

model components in the actual computer model.

The process elements within the boundary of the model, by status and actor are listed from

information provided from phase five (step 6.1.1). Each of the process elements are considered in

turn to determine if any can be treated as a phantom (processes which contain only a workflow

input and no practice can be identified that would influence the characteristics of the workflow).

Figure 8.4 in the previous section shows fifteen process elements that can be treated as a

phantom in the CoffeePotCo validation case. These are effectively dormant processes that

provide a necessary interconnection. The SCOR documentation is a useful aid as it suggests a

range of example practices for each process element which help identify relevant practices and

focus discussions with the client.

Step 6.1.3 aims to describe the actual practice for the existing ‘AS-IS’ and ‘TO-BE’ supply system

for the process elements included in the model. The inputs and processes identified by the

195

analysis were then considered to describe how the inputs (and sources) are converted to produce

an output (to a destination) specified by each actor. Although there is no check after this stage,

step 7.2.2 was implemented to ensure that the descriptions were ‘correct’ from the perspective

of the client and that there are no unnecessary details, or omissions for the objectives of the

study.

8.3 Purpose of the evaluation of the methodology

The purpose of the evaluation of the methodology is to demonstrate that it is both initially

feasibility and has utility. This conforms to two of the evaluation criteria described by Platts

(1993) and later expanded upon by Tan and Platts (2002) and Blackwell (2003). Section 3.1

justified that the usability criteria is outside the scope of the preliminary validation but issues for

testing can be identified (see section 8.4). The following sections expand upon the feasibility and

utility criteria in the context of evaluating the methodology presented in this thesis.

8.3.1 Criteria for evaluating the feasibility of the SCM2

The criterion for feasibility has been further broken down by Tan and Platts (2002) to include: the

availability of information, timing and participation. There is no evidence of studies including an

evaluation of feasibility using the sub-criteria of timing and participation except in Tan and Platts

(2002). Blackwell (2003) considers the availability of information and offers a definition which has

also been used by Benton (2009). This includes evaluating whether sufficient details were

provided by each step in the methodology in order for each to be successfully completed

(Blackwell, 2003).

Benton (2009) notes that some significant issues could arise when discussing ‘participation’ but

like this study and Platts (1993) earlier work, more participants are required to discuss this sub-

criterion in more detail. The ‘timing’ sub-criterion can also be viewed in the same way although it

is important to note that the methodology does not claim to address project management

outcomes. Using Platts (1993) original definition of ‘feasibility’ and Blackwell’s (2003) definition

of Tan and Platts (2002) ‘availability of information’ sub-criterion the question used to evaluate

the initial feasibility of the SCM2 is shown in table 8.6.

Table 8.6 Summary of the feasibility criteria to be examined

Feasibility Sub-criteria

(Tan and Platts, 2002) Question addressed in this thesis

Can the methodology be followed to describe the actual practices to be included in the model?

Availability of information – whether sufficient details were provided at each step in order to complete them successfully (Blackwell, 2003)

Was there sufficient information required and provided by the steps to complete them successfully?

196

8.3.2 Criteria for evaluating the utility of the SCM2

The research programme identified that the preliminary test should also demonstrate that the

methodology has initial utility. In Platts (1993) terms, utility concerns testing that the process

prescribed by the SCM2 did provide a useful step in the creation of a conceptual model for SCM

applications. In the context of Platts (1993) original work this would mean that at a practical

level, it is possible to create a conceptual model that can be developed into a computer model. At

a subjective level, this would involve asking actual users to establish their reactions when using

the methodology. At this stage of the research the preliminary test focuses upon the practical

level because further applications are required with actual participants.

Tan and Platts (2002) provide further, a breakdown of the sub-criteria for testing the ‘utility’.

These include relevance, usefulness and facilitation. Tan and Platts (2002) do not expand on what

is meant by ‘relevance’ but Blackwell (2003) offers a definition for usefulness and facilitation.

Table 8.7 applies these definitions in the context of this thesis.

Table 8.7 Summary of the utility criteria to be examined

Utility Sub-criteria

(Tan and Platts, 2002) Question addressed in this thesis

Does the methodology aid a user to describe a useful and relevant set of actual practices to be included in the computer model?

Relevance – No definition available Is the outcome from the methodology (description of the actual practices to be represented in the computer model) applicable for the purpose at hand?

Usefulness – Blackwell (2003) described this as whether the worksheets and tools included in the methodology helped the would-be user to progress through it.

Are there any significant omissions or differences between the outcome from the methodology (description of the actual practices to be represented in the computer model) and the computer model (how the actual practices were represented by the model components in the computer model)?

Facilitation – Blackwell (2003) described this as the problems that may arise when using it in practice and any additional comments or areas of concern that need to be addressed

Did any problems arise when using the methodology? Any areas that need to be addressed in further work?

8.4 Evaluation of the initial feasibility of the SCM2

The validation case demonstrates the methodology can be followed to arrive at the actual

practices to be included in a computer model. The initial feasibility is assessed by following the

prescribed steps in the methodology applied to the test case by the researcher. The criteria

discussed in section 8.3.1 are used to evaluate the initial feasibility of the methodology. Section

8.5.1 identifies issues that should be the focus of further refinement and testing particularly

addressing the limitations of the preliminary validation discussed in chapter three.

197

8.4.1 Evaluation of the availability of information required by the SCM2

The methodology requires information for each of the steps prescribed from three distinguishable

sources:

1. From information provided by a previous step in the methodology

2. Utilising the SCOR methodology for domain knowledge

3. Consultation with client sources (individuals knowledgeable of the supply system and/or

decision-makers)

On the whole the process could be followed with ease because each phase noted clearly the

points of entry and exit. Each step also included what information is required from any previous

step. The methodology also allows for iteration between steps when alterations have been

identified, when validating parts of the draft conceptual model. It was also clear when the client

should be involved to provide information, or mainly to clarify, or to verify information that had

been extracted from SCOR.

A key benefit and novelty of the methodology developed is that it utilises domain knowledge

provided by the Supply Chain Council SCOR model. It was previously argued that this could

provide an opportunity to aid a user to create a conceptual model in the context of SCM

applications. The SCOR process reference model was used to provide information in each of the

phases of the methodology. The aim was not to replace the need for interaction between the

stakeholders in a simulation project but to make any consultations more efficient and focused. In

the CoffeePotCo development case it was observed that using domain knowledge from an

existing process reference model could provide an avenue to aid a user to create a conceptual

model. It can aid in the identification of information to define a supply problem so that it can be

communicated using established terminology, provide information to drive the analysis and help a

user to justify any decisions that need to be documented.

The information required by each phase in the SCM2 and any comments on how the information

was used by following the steps prescribed for the CoffeePotCo validation case are shown in

appendix H. Comments are made relating to, using the domain knowledge, how information from

a previous step was used and how interaction between stakeholders involved in the conceptual

modelling stage was improved. The analysis identifies some key observations when using SCOR

for this purpose is shown in table 8.8.

198

Table 8.8 Key observations from an analysis of the information requirements for the SCM2

Information required by the methodology

Key observations

Clarity of terms and means of communication

SCOR model offered clarity and a means of communicating the supply chain problem using the predefined descriptions of supply chain performance attributes, improvement and supply setting

Describing the objectives

The objective of study defined in terms of SCOR performance attributes was relatively straight-forward to define a metric for delivery performance and inventory cost. SCOR provided information on how the metrics were calculated and the processes that provided the data sources. The actors were defined using the methodology to ensure that the proceeding analysis could be undertaken with the correct measurement span. An issue arose when describing the ‘Inventory days of supply’ metric which is only one of the metrics that SCOR does not define data sources. The supply chain council suggests this can be extracted from an existing system (e.g. accounts system). For the purposes of building a model this may mean that this activity needs to be represented in the model, or the SCOR documentation needs to be improved to identify which processes provide the necessary data to calculate the metric. In this case, the value of inventory is calculated by multiplying current finished stock level with the cost per unit – an input could be identified that satisfied this need.

Describing the improvements

SCOR could be used to describe the decomposed processes for each supply chain improvement. Unlike the refinement cases, the improvement in the CoffeePotCo case was not explicitly described in the practice guide. This did not present a problem because the descriptions could be used to identify which processes would be affected by the change. The steps in the methodology were sufficient to cope with this scenario, with interaction with the client to verify.

Describing the inputs and interconnections in the model

Once the supply problem was described in detail it was relatively straight forward to use the information provided by the SCOR model (e.g. inputs and their sources) to undertake the boundary setting analysis. The documentation (SCOR reference library for simulation modelling) developed was useful in this activity and it can be observed that embedding the information into a tool could provide an opportunity to automate the steps necessary to provide the information necessary when deciding the model boundary. This stage can be tedious and time consuming, automation would eliminate the need for steps to be completed manually (see section 8.6 for a further discussion) and hold accurate information which is specific to the needs of simulation modelling.

Deciding what to include in the model

The information describing each process and input was useful when deciding on how to treat each process element in the model boundary. The process was greatly improved by documenting the decisions and providing rationale.

Identifying and describing actual practice

The SCOR practice guide was useful when identifying actual practices for each process element and describing them. It is intended that this will help focus and structure any interactions between the modeller and client (in this case the information was extracted from a discussion of the computer model and one of the authors of the Taylor et al., 2008 paper).

It was clear from the evaluation that SCOR offered considerable benefits to focus and provide a

structure when creating a conceptual model due to the information that can be extracted to drive

each step. There were however some notable weaknesses, not for the SCM2 itself but in order to

maximise the potential of using a supply chain process reference model (in this case SCOR) in the

conceptual modelling stage of a simulation project. This included the need for a reference library

to provide information on the SCOR process elements and the necessary interconnections

between them so that it can be used for simulation modelling purposes. The key limitation is that

SCOR focuses upon describing a single organisation that sits within a supply chain. SCOR needs to

be further developed on how the practices, processes, interconnections (i.e. clarify the inputs and

outputs to and from suppliers and customers) and metrics (i.e. ensure that data sources are

described for all metrics) are described within and between suppliers and customers in a supply

system.

8.4.2 Evaluation of the availability of information provided by the SCM2

The methodology provides information from each of the steps prescribed, that are used in two

ways:

1. To provide information for a proceeding step in the methodology

199

2. To provide information necessary to draft, and later document, the finalised version of

the conceptual model

The process laid down in the methodology could easily be followed to provide the necessary

information. The methodology aim is to draft and then finalise the conceptual model by

describing the computer model to be developed. This was gathered from each of the relevant

outputs from the steps within the methodology. In the case of the CoffeePotCo validation case

the end result was a list of actual practices which was comprehensive and delivered in a more

structured and focused way. In order to arrive at the list of actual practices the following

information needed to be provided shown in table 8.9.

Table 8.9 Key observations from an analysis of the information provided from the SCM2

Information provided from the methodology

Key observations

Description of the supply chain problem

A structure was provided in order to present the objective, improvement and setting. It was also checked to ensure that the improvement in the Coffeepot Co case would bring about change to achieve the set objectives. This is an important phase that needs checking with the client to ensure that the subsequent analysis is completed effectively (the details provided in the supply problem drive the following analysis).

Supply chain performance metrics to measure each objective, how they are calculated and necessary data sources for each metric and actor

Using a predetermined format this could be described using SCOR terminology and process descriptions, which would aid in communicating the problem between the stakeholders in the simulation project

Decomposed business processes necessary to represent each improvement for each actor

As above

List of process elements and inputs and decision on their boundary status

Improves decision-making and documentation of decisions made

List of process elements that have been treated as ‘phantoms’

A number of process elements could effectively be treated as a ‘phantom’; this was easily displayed in the table provided.

The methodology utilises the strengths also held by the SCOR model (discussed in chapter six).

For instance, SCOR is a process framework developed with partners from a range of different

industries. It can be used to communicate supply chain processes, inputs and outputs to each

process, metrics and how they are calculated, practices and where they are implemented in a

universal way. This is important because a critical problem in simulation modelling is defining the

problem sufficiently and accurately so that the content of the model can be determined. The

SCM2 aids a modeller through this process in a structured and focused way and improves

communication between project stakeholders by documenting any rationale for the decisions

made.

8.5 Evaluation of the initial utility of the SCM2

The validation case demonstrates the methodology which aids a user to describe a useful and

relevant set of actual practices to be included in the computer model. The initial utility is

examined by comparing the model components implemented in the computer model, against the

200

actual practices that the methodology indicated should be included. The criteria discussed in

section 8.3.2 are used to evaluate the initial utility of the methodology. Section 8.5.2 identifies

issues for testing the utility criteria and addresses any limitations of the preliminary validation as

described in chapter three.

8.5.1 Relevance of output derived from the SCM2

The outcome from the point at which the methodology is applied is relevant for the purpose at

hand. A set of actual practices to be modelled could be described from the information provided

in the previous steps and using the SCOR model (presented in appendix G). It can be suggested

that following a structured approach can improve the rigour in the process of conceptual

modeling. In particular, the accuracy of the descriptions provided should be improved by

following the necessary checks within each phase and the final validation procedure (not

considered in the validation case). This addresses the need that conceptual modelling usually

requires iteration between steps in the methodology to address any changes/alterations deemed

necessary.

Both the modeler (in this case the researcher) and client (in this case one of the paper authors)

are involved in the description which has been checked within the phases of the methodology.

These checks were in place to improve both the validity and credibility of the draft conceptual

model. This is strengthened by embedding predefined domain knowledge that was originally

designed and tested in 70 world-class manufacturers from diverse industry segments (Stewart,

1997). More recently, SCOR has often been regarded as an industry standard for evaluating and

improving enterprise-wide supply chain performance and management (Wong and Wong, 2008).

Using a reference model that has been widely developed, tested and applied in practice, present

new opportunities to develop methods and tools for conceptual modelling that can be used for

the practicing manager.

8.5.2 Usefulness of the output derived from the SCM2

The methodology can be used to provide useful output that can aid in the creation of a

conceptual model for SCM applications. This can be shown by demonstrating that no significant

omissions or differences occur between the outcome derived from the methodology (description

of the actual practices to be represented in the computer model) and the computer model (how

the actual practices were represented by the model components in the computer model).

Appendix G provides a table that compares the actual practices to be modelled, how each

practice is represented in the computer model (for the CoffeePotCo as presented in Taylor et al.,

2008) and makes some comments on any omissions or differences.

201

The comparison showed that all the actual practices had been represented in the computer

model but the differences resided on the whole in how they were implemented. This was

expected as it was previously noted that the conversion from the descriptions of actual practice to

model components is influenced by a number of factors. However, an observation can be made

that the description is detailed enough to aid the user to perform the conversion with some

guidelines. In particular the description of the actual practices had been described by identifying

the boundary of the model at the required level of detail based upon knowledge of the domain

and with structured consultation with the client.

The list of actual practices was comprehensive because the methodology could be followed to

identify what to include, or not, and checks were in place to ensure that they were correct from

the modellers and clients perspective. In the case of the computer model developed in Taylor et

al., (2008) no structured analysis was undertaken (i.e. analysis relied upon the experience of the

modeller) and the practices to be modelled were not explicitly documented. The design choices

and evaluation of the content of the model were not presented in the Taylor et al., (2008) paper

but decisions were taken as a group of modellers. For instance, the modellers had incorporated a

number of simplifications and assumptions into the model.

There were four practices that were considered as ‘core’ process elements and described in detail

during the description of the actual practices. These can be summarised as activities that make

up the ‘deliver’ process in the factory including:

The factory loads the product onto the distribution vehicle

The factory consolidates orders to suit container size

The factory collects orders from production for each container load

The factory packs the container, the time taken is dependent on container size

Interestingly the modellers for the CoffeePotCo validation case had simplified the four activities as

a single ‘shipping delay’ for both a full container load of ‘air freight’ and ‘water (sea) and truck’.

The methodology placed a greater weight on these activities than the modellers. This was evident

in the application as it was highlighted that significant debate was needed to adequately describe

the processes that would be influenced by the improvement. The inputs to the processes that

represent these actual practices would have been considered resulting in candidates being

included and the rationale defined. It has highlighted that the methodology has been useful in

providing a structured and comprehensive approach that has ensured that the participants in the

conceptual modelling process have considered and justified choices in the design.

202

The ‘shipping delay’ includes a transportation lead-time which was taken from Zeng (2003) who

provides an estimate and considers what the activities include. Zeng (2003, pg. 372) states that

the activities in the ‘deliver’ process ‘typically begins with consolidation, involves the transfer of

consolidated goods to the airport/sea port by rail or truck, storage in warehouses, loading, actual

transit, unloading, customs clearance, transfer to the destination and ends with receiving’. It can

be assumed that this description adequately includes the four activities described.

There are some other considerations that the four activities may have led the modeller to

consider. For instance, in the computer model an infinite capacity of loading and packing is

assumed and that shipments are made instantly. In the real world, these activities would place

constraints on the model and shipments will depend upon the availability and capacity of the

transportation models for each shipping method. The Taylor et al., (2008) paper did not discuss

whether these issues were significant or not in the discussion of the process parameters. It was

assumed that these practices could be simplified by representing them as a time delay. A benefit

of using the methodology is that the procedure did force the facilitator to justify decisions on

whether the processes should be included and how they should be represented.

A significant advantage of the methodology is its ‘usefulness’ because it provides a detailed and

comprehensive set of actual practices to be represented. It was previously argued in this thesis

that little attention is paid to a documented description of a conceptual model in publications and

there is little evidence of structured approaches being followed (e.g. lack of methods,

understanding). The design of a computer model or even, conceptual modelling, without

following a structured approach or documentation may lead to a model that is biased, based

upon the modellers perspective and experience of evaluating SCM problems using simulation (e.g.

over-simplification or too much detail). Significant value is offered by following a structured

approach as it utilises domain knowledge, consultation with client sources and checks have been

in place to ensure the correctness of the model. This reduces the prospect of over simplifying the

model or having too much detail which should lead to more valid and credible conceptual models.

8.5.3 How the methodology could be facilitated

The methodology could be followed to create a conceptual model but at present the guidelines

may require knowledge and expertise, particularly an understanding of the SCOR process

reference model. The methodology aids a facilitator to describe and document a supply problem,

formulate the model boundary, describe the detail of the model components to be included in

the model and a detailed validation procedure. Nevertheless, an expert facilitator is required to

203

follow the process, utilise SCOR and perform the analysis. The problems identified and areas that

need to be addressed in further work focus upon this central issue.

The purpose of using SCOR for domain knowledge was to potentially make the process of

conceptual modelling more focused and efficient. It is clear that focus is clearly delivered by the

proposed methodology and efficiency can be greatly improved by identifying opportunities to

simplify the analysis conducted at the conceptual modelling stage. It has been argued in the

literature that SCOR can have many benefits when combined with a simulation approach (e.g.

Kasi, 2005; Persson and Araldi, 2009). This thesis agrees with this proposition and demonstrates

that it is feasible and useful at the conceptual modelling stage but that some significant

drawbacks exist that need to be addressed by the SCC and the wider supply chain simulation user

community.

Table 8.10 shows that a major strength of SCOR is the shear range and detail of its descriptions of

practices, metrics, processes and flows but the list is still by no means exhaustive. The key

weakness is that SCOR lacks detail in how a supplier and customer interact with an organisation.

Using Harland’s (1996) term it is strong at describing the business processes within the boundary

of the organisation and to an extent dyadic relationship although the flows between them are not

adequately described. Moreover it does not describe how practices, metrics and interconnections

between processes can be implemented across a chain or network. Improvement in these areas

would not only improve the utility of the SCOR model itself but for conceptual modelling and for

building and validating simulation models in general.

Table 8.10 Evaluation of ‘facilitation’ when using SCOR Descriptions

offered by SCOR Observation in

CarCo case Comment

SCOR practices Practice not adequately covered

Practices could be identified but they are by no means exhaustive

Difficult to ascertain how a practice may be implemented in more than one organisation and/or between suppliers and customers

SCOR metrics No issues identified

SCOR metrics are extensive compared to alternative offerings in the literature (e.g. Beamon, 1999; Gunasekaran et al., 2001, Shepherd and Gunter, 2006)

Provide detailed description of how they can be calculated

Some discussion of how they can be measured across a supply chain but main focus is within the firm

SCOR decomposed business process descriptions

No issue identified

From a practice and/or metric the processes and inputs to that process can be identified

If no practices could be identified the SCOR decomposed business process descriptions can be selected

204

8.6 Identification of issues for testing

Testing is required to improve the validity and generalisability of the methodology presented in

this thesis. This section identifies areas for testing, particularly the usability of the methodology

which has yet to be preliminarily validated. Additionally, to further improve the feasibility and

utility of the methodology.

8.6.1 Feasibility

The methodology is shown to be initially feasible but further refinement and testing is required to

demonstrate the ‘general’ feasibility of the methodology. Platts et al., (1998, pg. 521) expresses a

view to improve the general feasibility:

‘By repeating the process in several companies and using different facilitators provides greater confidence in the more general feasibility of the process can be achieved’

In the context of this thesis this requires repeating the methodology for several different SCM

applications using different facilitators. The areas that should be particularly focused upon in

future refinements and feasibility testing include:

1. How different facilitators utilise the domain knowledge provided by SCOR – This would

be of particular interest as the methodology requires at present ‘expert facilitation’. The

question to be addressed is to demonstrate how SCOR can be used to ensure the process

of conceptual modelling is more efficient and focused

2. Test how different participants are involved in each step – The methodology suggests

how participants should be involved in the procedure but this has yet to be tested

3. Test how the information provided to draft a conceptual model is used at the final

validation phase – The methodology does not test the final validation phase. This is a

significant and substantial area for further research activity in its own right.

8.6.2 Utility

The methodology is shown to have initial utility but further refinement and testing is required to

generalise from the preliminary findings. Similar to the discussion for ‘feasibility’ further

applications and observation of actual facilitators is required. The refinement and testing would

benefit greatly by interviewing the facilitators and participants who are following the

methodology to identify how it can be improved. This would include:

1. Relevance of the methodology to create a conceptual model that is more valid and

credible – Evaluate how a modeller may use the output provided from the methodology

to build a computer model

2. The usefulness of following a structured approach as opposed to no formal methods –

The thesis does not claim that the methodology offers a ‘better’ approach but has

205

discussed the benefits of following a structured approach and presented opportunities to

improve it. Further work should observe the differences between alternative approaches

to conceptual modelling to learn from them and identify the value of following the

methodology.

3. Identify from the participants whether any problems arose or need to be addressed

when using the methodology – Identify any issues and areas for further refinement from

participants using the methodology

8.6.3 Usability

The thesis does not claim that the methodology has been validated against the usability criteria.

The research methodology chapter argued that the usability is a test that should be conducted

once the methodology can be shown to be initially feasible and have utility. Usability would

involve observing actual participants to address the question of how easily the methodology as

prescribed could be followed. Table 8.11 below presents a summary of criteria that should be

used to test the usability of the methodology.

Table 8.11 Summary of the usability criteria to be examined Usability

(Platts, 1993) Sub-criteria

(Tan and Platts, 2002) Question addressed in this thesis

How easily can the methodology be followed?

Clarity – Blackwell (2003) defined this as how well the methodology was structured

Are the steps in the methodology clear and well structured in order for a potential user to achieve the desired outcomes?

Ease of use – Blackwell (2003) defined this as how easy the methodology was to be used and understood

Can the methodology be followed with ease and be understood by a potential user?

Appropriateness – Blackwell (2003) defined this as the length of the methodology and how it might be either extended or reduced

Is the methodology the desired length, should any of the steps be extended or reduced?

Observations at this stage of the research project can be made but these can only be claimed

from the perspective of the single researcher. These observations are included in appendix I from

the perspective of the researcher when applying the methodology to the CoffeePotCo validation

case. These initial researcher observations are used to identify issues that require further

refinement and testing with actual participants following the methodology as prescribed. The

observations include:

1. The phases and steps in the methodology were clear, well structured and detailed – An

overview is provided that demonstrates how each phase should be conducted and a

detailed table describes each of the steps, information requirements and what it

provides, and how participants are involved in the process.

2. The methodology should be used by both experts and benefit novice users – The

methodology can be followed with ease by the researcher but further work should focus

on simplifying the methodology and identifying ways to facilitate the process with little

206

human interaction. In particular, how to embed the domain knowledge offered by SCOR

without the participants needing to be competent in its use.

3. The methodology is appropriate but can be improved to reduce time consuming

activities – The methodology includes a host of guiding principles and procedure that is

unique for evaluating SCM problems using simulation. Using SCOR had a number of

advantages but the analysis could be improved to reduce time consuming and repetitive

activities. It cannot be claimed at present that this speeds up the process of conceptual

modelling but there are many opportunities to refine the methodology so some steps can

be automated and thus become redundant.

It would be of particular interest to observe both expert and novice potential participants and

facilitators of the methodology. This would build upon the studies by Willemain (1994; 1995) and

Willemain and Powell (2007). An aim of further refinements must concentrate on identifying

ways to minimise the need for expert facilitation so that novices could potentially use it. Three

opportunities to address this need are discussed in the following section.

8.7 Opportunities to improve the SCM2

The refinement and validation stages have led to three opportunities that can be identified to

further improve the methodology. These opportunities provide further avenues to extend the

work and ensure that the methodology is accessible to a wider audience and are both usable by

expert and novice users. These opportunities are listed below and discussed in the following

sections:

1. Role and impact of automating certain steps in the methodology

2. Strengthening the utilisation of SCOR to provide domain knowledge for conceptual

modelling

3. Develop a web-based tool that can facilitate the methodology and make it more widely

accessible for potential users

8.7.1 Role and impact of automating the methodology

The application of the methodology to the development and validation cases using predefined

templates in an Excel spreadsheet, added additional functionality to how the methodology was

used. There is an opportunity to take advantage of additional functionality offered by a

spreadsheet package to automate a number of key concepts that were identified and described in

chapter six.

207

The usability and facilitation of the methodology could also be greatly improved by incorporating

a guide for using SCOR in the context of conceptual modelling (discussed in 8.6.2). In particular

any potential errors for using the domain knowledge to provide information can be reduced and

some steps can be made redundant (e.g. a macro could perform a set of activities). These

opportunities are presented in table 8.12.

Table 8.12 Opportunities to automate aspects of the SCM2

Automation concept Description Link to key concept described in the

design

Select predefined practices and objectives

The detail provided from SCOR that describe practices and objectives at stage one and used to identify the core process in the model can be selected from a predetermined catalogue

Key concept 4: Identification of the core processes that need to be modelled, their inputs generated from a source process element (using SCOR detail provided in key concept 2 and 3)

Identification of interconnections between processes

The inputs to each process are defined by SCOR. The data required to perform the analysis to identify candidate process elements for consideration can be predefined and generated as the methodology is followed (e.g. without copying and pasting from an independent SCOR guide)

Key concept 4: see above

Discrimination of candidate process elements

A predetermined macro incorporated into the spreadsheet application can perform this activity without any human interaction. This would effectively make phase three redundant. The analysis would be activated when a user makes decisions at the model boundary formulation phase.

Key concept 5: Process elements that have yet to be included in the model can be classed as candidates for possible inclusion

Provide information to drive the model boundary formulation

A macro incorporated into the spreadsheet application can provide the information from phase four to phase five

Key concept 6: Candidate process elements are considered in turn for inclusion in the model as they form a critical interconnection between core processes and the real world

Automate the phantom process rule

Processes that meet the ‘phantom’ criteria can be automated making the step redundant in phase six

Key concept 7: Included process elements are considered in turn to identify those that could be simplified

Create a draft conceptual model to be validated in the final phase

The ’text’ descriptions provided from phases in the methodology used to draft the conceptual model can be generated using a predefined macro and template in a spreadsheet application.

Key concept 10: The conceptual model is documented and validated

8.7.2 Strengthening the utilisation of domain knowledge

The development of the methodology has shown that there is a need for domain knowledge in

the process of conceptual modelling. One source of this knowledge includes SCOR; an existing

supply chain operations process reference model widely used in practice. The benefits of using

SCOR for simulation applications, particularly at the conceptual modelling stage have been noted

in this thesis. Additionally a number of observations have been made to improve the usefulness

of using SCOR and how it can be further developed for the purposes of simulation modelling.

Firstly, the documentation of SCOR needs to be presented with more detail on how a practice and

metric is to be implemented between supply chain actors. Secondly, the documentation needs to

be clear on how different manufacturing environments (e.g. MTO, MTS, ETO) can use different

configurations of process elements, as there is significant commonality between process types

within each environment. Most significantly SCOR does not attempt to include typical practices

208

such as ‘MRP’ in its planning processes and some other practices such as ‘kanban’ are expressed

in scheduling of product deliveries but not included in the planning descriptions (e.g. plan number

of kanban cards). These are areas that would strengthen the domain knowledge provided by

SCOR to enable the information to be used more effectively and with greater ease.

8.7.3 Development of a web based tool

A web-based tool could be created that combines the methodology with the functionality of a

spreadsheet which could perform the actions necessary to create a conceptual model. The aim

would be to create a user interface which would guide the user through the steps; note

information needs (e.g. from SME’s, SCOR) and involve the necessary participants (bringing

together the opportunities noted in sections 8.6.1 and 8.6.2). A spreadsheet application would

provide many benefits as it can include predefined templates (e.g. collect and present data), aid in

the facilitation of a guide, perform some of actions that can be automated and be more widely

accessible for potential users. This would improve the usability and utility of the methodology

and provide significant opportunities to reduce the complexities of developing simulation

conceptual models.

8.8 Chapter summary

This chapter has implemented stage V of the research methodological programme and addressed

the final research objective of the thesis. The preliminary validation was undertaken by applying

the methodology that has previously been refined and aligned to the specification to a validation

case (CoffeePotCo). The key observation was that the methodology is both initially feasible and

has utility but further refinement and testing is required. Particularly the ‘usability’ criteria have

yet to be validated and there is a need to extend the preliminary feasibility and utility evaluation.

The key issue for testing is to apply the methodology in different industrial contexts and to

observe potential facilitators (independent from the researcher) and participants in how they

follow the methodology.

It was shown that a methodology can be followed to create a list of actual practices to be

modelled that are both useful and relevant. This was compared with an actual model published in

the literature so that the ‘utility’ of the methodology could be examined. The methodology at

present requires ‘expert facilitation’ to follow the methodology but the majority of issues that

require further refinement surround the use of SCOR. This is an important finding as SCOR is

commonly used for simulation modelling (this is one of the first studies that has considered it for

the purpose of conceptual modelling) but the weaknesses have not explicitly surfaced except in

this study.

209

The chapter also discussed some opportunities to improve the methodology and provide further

avenues for research. A central aim for developmental work should focus upon developing a

web-based tool that could aid in the facilitation of the methodology. This tool could also take

advantage of opportunities to automate the key concepts and steps identified. There is also a

significant opportunity to strengthen SCOR for simulation modelling, particularly how it can be

utilised to provide some of the domain knowledge required for conceptual modelling.

210

Chapter 9 Conclusion and future work

The final chapter concludes the thesis by summarising the primary and secondary contributions

made by the thesis, conclusions from each of the research objectives and questions, limitations of

the study and implications for further work. The primary contribution delivered by this thesis can

be summarised as:

“The development, refinement and preliminary validation of a methodology that utilises

domain-knowledge combined with a procedure that can be followed to create a

simulation conceptual model for SCM applications”

The thesis argues that the primary contribution is both relevant and significant; it will also provide

benefits to both research and practice. The main limitation is that testing is required to expand

upon the preliminary validation and an opportunity exists to develop the methodology into a

web-based application tool. The chapter structure therefore addresses:

Original contributions made by this thesis (section 9.1) – details that the primary

contribution of the thesis and associated secondary contributions

Conclusions from the research objectives and questions (section 9.2) – Reviews each of

the objectives and questions to demonstrate that they were adequately addressed

Limitations of study (section 9.3) – Identifies that further testing is required in different

industrial settings and with actual users to improve the ‘validity’ and ‘generalisability’ of

the SCM2

Implications for further research and practice (section 9.4) – Reviews the contribution

made in the thesis in light of Robinson (2006) list of opportunities for advancing research

in the area of conceptual modelling

9.1 Original contribution made by the thesis

This section summarises and justifies the primary and secondary contributions made by this

thesis. Firstly, section 9.1.1 discusses the primary contribution and secondly, section 9.1.2

discusses each of the secondary contributions. These contributions are noted in table 9.1 along

with the gaps in existing research contributions, the research objectives, questions addressed and

with references to the location of the discussion in the thesis.

211

Table 9.113 Research contribution made by this thesis Research contribution made by this

thesis Gap addressed in existing research

Research Obj./Q’s

Thesis ref.

Primary research contributions:

1. Development of a methodology that utilises domain-knowledge with a procedure that can be followed to create a simulation conceptual model for SCM applications (summarised in section 9.1.1.1)

The primary contribution of this thesis is a seven phase methodology that utilises domain-knowledge with a procedure that can be followed to create a simulation conceptual model for SCM applications. The key concepts are identified from considering the design issues for each of the requirements specified. The core idea is that SCOR is one source of domain knowledge that can potentially enable a more efficient and focused conceptual modelling process. There is little research on the domain specific requirements for conceptual modelling and no methodology currently exists. Although research, particularly the development of new theory in this area, has been noted as critical for the rigour of supply chain studies (e.g. Manuj, et al., 2009).

Obj. 2; Q3

Chapter 6 and 7

2. Preliminary validation of a methodology for creating simulation conceptual models for SCM applications (summarised in section 9.1.1.2)

The methodology is refined and its initial feasibility and utility is preliminarily validated by applying it to a different case application. The evaluation illustrates that the methodology is initially feasible but warrants testing of its feasibility and utility with original industrial case studies and potential users of the methodology. Additionally, comments are made about the usability of the methodology and an outline for rigorous testing is noted. There are no other methodologies available and one general framework (Robinson, 2004a; 2004b) exists which has been illustrated (Robinson, 2008a; 2008b) but with little detail or critical evaluation.

Obj. 3; Q4

Ch. 8

Secondary research contributions:

3. Examination of existing simulation conceptual modelling practice in SCM (summarised in section 9.1.2.1)

The different approaches to simulation conceptual modelling are identified with examples in literature. These include principles, methods of simplification, frameworks and methodologies. Research identified that no methodologies exists, one framework has been suggested, while there is a vast amount of contributions that discuss guiding principles for modelling in general. Robinson (2004b) does devote a chapter of his text to conceptual modelling concepts, but it lacked a detailed examination of practice, in particular in the context of evaluating supply chain problems.

Obj. 1; Q1

Chapter 4

4. Specification of the requirements for simulation conceptual modelling in SCM (summarised in section 9.1.2.2)

The requirements for an effective conceptual model, requirements of good methodologies and the requirements for simulation conceptual modelling in SCM are examined. The requirements for an effective model have been discussed and the requirements for good methodologies draw upon the work by Platts (1993) and publications that have used the criteria more recently. The requirement for conceptual modelling in SCM has yet to be adequately described; this includes defining what is meant by the term ‘supply chain problem’. This is detailed in terms of the range of supply chain improvements selected, to achieve supply chain performance measures within its supply setting.

Obj. 1 Q1

Chapter 5

9.1.1 Primary research contribution

The primary contribution as previously stated is the ‘development, refinement and preliminary

validation of a methodology that utilises domain-knowledge with a procedure that can be

followed to create a simulation conceptual model for SCM applications’.

This thesis has contributed to knowledge in the areas of conceptual modelling and supply chain

analysis.

In the area of conceptual modelling, this thesis has demonstrated that a methodology can be

developed that can combine a generic procedure for simulation conceptual modelling with

212

domain-knowledge to improve the efficiency and focus of a process that guides a user to create a

conceptual model. In this instance, domain-specific knowledge has been embedded in the form

of the Supply Chain Council SCOR reference model. Hence, the methodology can be followed, and

then therefore used to describe a computer model, which then may be built from a description of

a supply problem. In conceptual modelling, there was no established methodology for the

development of conceptual models; this work creates such a methodology. The initial feasibility

and utility of the methodology has been illustrated by applying the procedure with development

and validation cases.

In the area of conceptual modelling, we now know that:

Decision rules can be used to consider which business processes to include within the

model boundary from identifying the critical relationships between (core processes) and

within the setting (real world) of the processes that are associated with each objective

and improvement

Decision rules can be embedded in a generic procedure to simplify inputs to the model

and to determine when no further processes should be included in the scope of the

model (i.e. model boundary is set)

General principles, simplification methods, methods for representing model content and

validation methods (both within and at a final phase) can be incorporated into a general

and comprehensive procedure for conceptual modelling to minimise the types of

problems that could be encountered in a simulation project

In the area of supply chain analysis, the thesis has shown that embedding SCOR in a generic

procedure for simulation conceptual modelling can:

Aid in the description of a problem from the perspective of the client using standard

terminology and domain-specific process detail

Aid in determining how an objective can be measured using standard descriptions of

typical performance attributes and metrics; plus data collection needs from associated

business processes at different levels of detail

Aid in determining how each improvement can be represented by business processes to

implement each improvement at different levels of detail

Aid in determining the model boundary by providing information on the relationships

between business processes (i.e. interconnections between inputs and outputs germane

to each process element)

213

Aid in providing clear domain-specific guidelines for extracting information from a pre-

defined process reference model and when necessary focus consultation with people who

are knowledgeable about the system being represented

Aid in focusing consultation with people who are knowledgeable about the system being

represented to determine the detail of the actual practice that needs to be included from

the descriptions provided for each process element included in the model boundary and

simplified inputs

Despite SCOR purporting to be a comprehensive supply chain reference model, we know now that

it has the following deficiencies which could be improved to enable the information to be used

more effectively and with greater ease:

SCOR documentation needs to be presented with more detail on how a improvement and

metric is to be implemented between supply chain actors (e.g. not just within the focal

firm)

SCOR documentation needs to be clearer on how different manufacturing environments

(e.g. MTO, MTS, ETO) use different configurations of process elements as there is

significant commonality between process types within each environment

SCOR does not attempt to include typical practices such as ‘MRP’ in its planning processes

and some other practices such as ‘kanban’ are expressed in scheduling of product

deliveries but not included in the planning descriptions (e.g. plan number of kanban

cards)

The following section discusses in more detail the combination of a procedure and domain-

specific key concepts that incorporate domain-knowledge for SCM applications (discussed in

section 9.1.1.1). This is followed (discussed in section 9.1.1.2) by a discussion on the way in which

the research programme was structured to firstly develop the theory (stages I – III), followed by

refinement (stage IV) and a preliminary validation (stage V). Further work has been outlined in

this thesis to advance the area of simulation conceptual modelling, in particular for the purposes

of supply chain analysis and to test the methodology. This is outlined in section 9.4.

9.1.1.1 Summary of the SCM2: A procedure and domain-specific key concepts

The methodology has seven phases which have been described in detail in chapter 7 and

preliminarily validated in chapter 8. It incorporates a set of key concepts and a procedure for

simulation conceptual modelling of supply chain problems. These key concepts were identified in

chapter 6 after considering the design issues for each of the requirements specified in chapter 5.

214

The phases for the methodology were identified that incorporated each of these key concepts in

light of a general process for conceptual modelling. It can be argued that this is a first attempt to

identify specific concepts and a bespoke process for the supply chain domain.

The general phases of the methodology and associated key concepts are summarised in table 9.2.

The detail of the methodology is described and justified in a series of tables for each phase in

chapter 7. Each phase describes how information is required and provided, who participates in

each step, the tools that should be used to represent and document the model content, and the

necessary ‘checks’ to ensure the output is valid and credible. Iteration is required between steps

if a check had not been satisfied (requires a phase to be repeated), or a return to a previous step

is required if new information is generated (i.e. in the case of formulating the model boundary).

The methodology is entered when a client has a supply problem to be evaluated using a

simulation approach.

Table 9.214 SCM

2: Procedure and key concepts for SCM applications

Procedure Key concepts for SCM applications

Phase one: Describe the supply problem - The supply problem is described from the perspective of the client

1. Supply chain problem: describe the objective, improvement and supply setting

Phase two: Determine how each objective is to be measured – The objective is described in terms of how it will be measured

2. SCOR SCM performance metrics can be used to identify how an objective is to be measured

Phase three: Determine how each improvement is to be represented – The improvement is described in terms of how it is to be represented

3. SCOR practices can be used to describe each improvement to be evaluated

Phase four: Determine how the inputs and their sources interconnect within the model and with its immediate supply setting - Provide a list of model inputs and candidate process elements (NB: supplies information only to formulate the model boundary)

4. Identification of the core processes that need to be modelled, their inputs generated from a source process element

5. Process elements that have yet to be included in the model can be classed as candidates for possible inclusion

Phase five: Formulate the model boundary – Provide a list of processes and inputs included in the model

6. Candidate process elements are considered in turn for inclusion in the model, as they form a critical interconnection between the core processes and the real world

7. Included process elements are considered in turn to identify those that could be simplified

Phase six: Design the level of detail to implement each process and input included in the model boundary – Provide a description of how the actual practices are represented by the model components and relationships between them

8. The detail that needs to be included can be identified from the actual practice for each process element included and simplified in the model

9. Modelling practice should represent the essential complexity and detail of the actual practice to be evaluated

Phase seven: Document and validate the conceptual model – The draft descriptions provided from the phases and steps in the methodology are documented and validated

10. The conceptual model is documented and validated

215

The core proposition that underpins the key concepts is that the utilisation of domain knowledge

can enable a procedure for conceptual modelling that is potentially more efficient and focused. It

was proposed in section 6.3 that the Supply Chain Council SCOR model presents a number of

opportunities to realise the proposition in comparison with alternatives. For instance, it has

strengths in each of Becker et al., (2003) qualities for an effective model. In particular, it is widely

used in both practice (relevance) and for simulation purposes (economic efficiency), as it provides

clear (clarity) and correct (correctness) domain knowledge that can be used to compare supply

chain configurations (comparability).

Section 6.4 demonstrated that SCOR could be used to provide detail on the improvements (has a

list of over 420 ‘best practices’), objectives (describes a comprehensive list of ‘performance

attributes and metrics’) and the supply setting (the ‘processes’ and relationships between them

depicted by their source ‘inputs’). This was demonstrated by extracting the detail necessary to

describe two typical supply problems and how they have been evaluated from five representative

cases in the literature. Although SCOR presents great potential in the area of conceptual

modelling a number of limitations were identified. These were noted in the discussion of the

refined design meeting the requirements for conceptual modelling of supply chain problems (C.f.

section 7.5.3) and demonstrated in the evaluation of the methodology (C.f. section 8.3). These

limitations were considered in more detail in section 8.5 as opportunities to enhance and further

develop the SCOR model and areas for further study to improve the SCM2.

9.1.1.2 Development, refinement and validation of the SCM2

A review of the research issues for conceptual modelling in the context of SCM demonstrated that

a gap exists for a SCM2 that utilises domain-knowledge combined with a procedure. This gap was

proposed to be both a relevant and significant research issue for both developing new theory and

practical application. It was argued (C.f. section 2.1) that improving supply chain performance can

have a significant impact upon an organisation’s performance (e.g. Stewart, 1997; Tan et al.,

1999; Kannan and Tan, 2005; Li et al., 2006). One of the challenges faced by companies is to

identify how this potential could be evaluated (Weaver et al., 2007). This is problematic due to

the inherent complexity in supply chain problems (C.f. section 2.2). It was shown (C.f. section 2.3)

that simulation is one popular method that is widely used to evaluate the complexity of supply

chains (e.g. Ridall et al., 2000; Huang et al., 2003; Van der Zee and Van der Vorst, 2005; Kleijnen,

2005). One of the critical, but least understood, stages of a simulation project is the creation of

the conceptual model (e.g. Law, 1991; Robinson, 2006).

216

An examination of simulation studies in the context of SCM showed that little has been written

about the conceptual modelling stage. However, Manuj et al., (2009) identify conceptual

modelling as an area that requires more attention to improve the rigour of future research studies

that use a simulation approach. One reason for this could be the lack of detailed reporting of the

design choices made during the conceptual modelling stage. A second reason has been suggested

by Robinson (2006a; 2006b) and Wang and Brooks (2007a) of a severe lack of methods and

procedures that could be used by experts and novice users. The thesis has argued that a

methodology could incorporate aspects of existing practice and identify novel concepts that could

improve understanding, usage and the teaching of simulation conceptual modelling.

The design for the methodology is based upon a strong conceptual base, (theoretical) and the

refinement and preliminary validation of the methodology, by applying it to three SCM

development and validation case applications (empirical). This includes the establishment of the

requirements for the methodology (stage II of the research programme) and a discussion of each

of the design issues for each requirement in the outline design (Stage III of the research

programme). The refinement of the methodology demonstrated that the methodology has met

each of the requirements for 1) an effective conceptual model; 2) a good methodology and 3) the

specific requirements for conceptual modelling in SCM simulation projects. The outline design

presented a synthesis of the key issues that arose when considering each requirement. The aim

was to identify the key concepts for inclusion into a specific procedure that addressed the need of

conceptual modelling for SCM applications.

The developed methodology has been refined using two development cases, one fictional

(‘BeerCo’), and the other being a complex and detailed industrial case (‘CarCo’) against the

specification of requirements. A preliminary validation using a different supply problem

(‘CoffeePotCo’) was undertaken to evaluate the methodology against the ‘feasibility’ and ‘utility’

criteria. This is in line with similar contributions that develop methodologies, such as those that

develop a methodology but have no claimed testing (e.g. Apaiah, 2006; Lima, 2008) and those

that have refined and preliminarily validated a methodology (e.g. Gan Kai, L.W., 2007; Benton,

2009). The limitations of the methodology were identified in chapter 8, after identifying issues for

further testing of the ‘feasibility’ and ‘utility’ in more industrial settings with potential users (C.f.

section 8.6). This also includes identifying issues for future testing of the ‘usability’ of the

methodology.

217

9.1.2 Secondary research contributions

In addition to the primary research contribution noted in section 9.1.1, three other advances have

been made in the area of simulation conceptual modelling in SCM. The contributions evolved

around underpinning the theoretical context of the developed and evaluation of the SCM2. These

can be termed advances to knowledge as it has already been argued that research in the area of

conceptual modelling is spare and very little has been applied in a SCM context. Each of the

secondary research contributions are noted also in table 9.1 with associated detail.

9.1.2.1 Examination of existing simulation conceptual modelling practice in SCM

A secondary advance made by this thesis includes the examination of existing simulation

conceptual modelling practice in SCM. Many researchers have noted that no widely accepted

approach exists in the area of conceptual modelling (e.g. Pace, 2000a; 2000b; Robinson, 2006).

The approaches that can be found are classified as guiding principles, methods of simplification

and frameworks. A fourth is proposed to include ‘conceptual modelling methodologies’; these

were differentiated from the other three approaches and is the focus of this thesis. The literature

showed an abundance of contributions that offered general guiding principles and methods of

simplification. The majority of the findings are relevant to conceptual modelling but very little

research was dedicated to providing specific methods and procedures in this critical stage of a

simulation project.

Frameworks could be identified for simulation modelling in general (e.g. Shannon, 1975; Law and

McComas, 1991; Musselman, 1994; Banks, 1999), which all recognise the conceptual modelling

stage. The detail of how to create a conceptual model is an area underdeveloped except, to an

extent, in Robinson (2004a; 2004b) general framework. However, Robinson’s framework

presented a number of weaknesses, including: that the framework did not address ‘how’ to create

a conceptual model in detail; did not address the specific needs of the SCM domain and had not

undergone any extensive testing or even evaluation. Interestingly, Robinson recognised the need

to review methods for simplification, conceptual model validation, and ways to represent and

communicate a conceptual model, although they were not incorporated into the framework.

The methodology developed in this thesis has integrated, where possible, the guiding principles,

methods of simplification, and ways for representing and documenting the content of a

conceptual model. In addition to this, the discussion of conceptual model validation is arguably of

great importance and interest to practice. In relation to this, a ‘hypothesis test’ and ‘expert

review’ were found to be applicable to the conceptual modelling stage. Additionally, the

methodology can incorporate principles and methods that can improve the validity and credibility

218

of the model into the procedure. Therefore, the methodology is detailed and comprehensive, and

has been developed specifically in the context of SCM applications.

The problems encountered in simulation modelling are examined demonstrating the benefits and

need for a greater understanding of conceptual modelling. The majority of work has centered on

a critical aspect of conceptual modelling: determining the most appropriate model complexity and

level of detail (e.g. Brooks and Tobias, 1996; Chwif et al., 2000). Additionally, a mechanism is

discussed for communicating and representing a conceptual model so that it can be shared

amongst the project team and fundamentally used to develop a computer model. A range of

approaches were identified for representing a conceptual model, which could be used in the

process of conceptual modelling.

9.1.2.2 Specification for simulation conceptual modelling in SCM

Another secondary advance includes a specification for simulation conceptual modelling in SCM.

This details the requirements for an effective conceptual model, requirements of good

methodologies, and the specific requirements for conceptual modelling in SCM.

The requirements for conceptual models (e.g. WIllemain, 1994; Brooks and Tobias, 1996;

Robinson, 2004a; 2004b) and characteristics of methodologies (e.g. Platts, 1994; Platts and Tan,

1996a) have been documented in previous research. These are both reviewed in light of the

applicability to conceptual modelling and the evaluation of SCM problems. The aim was to draw

upon recent SCM examples and to reinforce a set of requirements that would guide the design for

the methodology. It was identified that the methodology should address the fundamental need

to ‘keep the model as simple as possible’ and to create a conceptual model that is both ‘valid’ and

‘credible’. This focuses upon the ‘probable’ accuracy of the conceptual model from both the

modeller and client’s perspective. In relation to the characteristics of a good methodology, these

were found to include ‘participation’, ‘points of entry’ and a ‘procedure’.

One area that is novel includes identifying the requirements of evaluating supply chain problems.

It was argued, in section 5.3, that the methodology should capture the complexity and detail of a

supply chain problem for a given objective within its supply setting. Therefore, the implications

for this were to define what is meant by complexity and detail in the context of SCM, the range of

objectives to measure performance and how the interconnections between them and the supply

setting can be determined. A detailed review provided a synthesis of the characteristics for each

of these needs. This included:

219

Complexity of a supply problem – size, business process types and linkages between

actors and business processes

Detail of a supply problem – level 0: supply network composition (supply chain

structure); level 1: business process types (roles an actor plays in the supply chain); level

2: process categories (describes an organisation operations strategy); level 3: process

elements (fine tuning of the operations strategy) and level 4 and beyond: implementation

level (activities and actions required to implement SCM practices that are unique to the

organisation)

Range of supply chain objectives – level of detail within the business process, business

unit and across the whole supply chain

Interconnections within the supply setting – identification of the critical and necessary

links between the improvement and objectives

9.2 Conclusions from the research objectives and questions

The overall aim and purpose of this thesis was to develop and preliminarily validate a

methodology to aid in the creation of a conceptual model for supply chain problems. The

required specification for the methodology was documented (objective one); a SCM2 developed

and refined to meet the required specification (objective two) and preliminarily validated to

demonstrate the SCM2 is initially feasible and has utility (objective three). These research

objectives were addressed in different parts of the thesis (shown in table 1.1) and implemented

by the stages distinguished in the methodological programme (shown in figure 1.1). This section

considers each research objective and underlying research question to demonstrate that the

objectives set out in this thesis have been achieved.

9.2.1 Objective one: Documentation of required specification

The first objective concerns the documentation of the required specification for the SCM2. This

objective was addressed by answering two research questions:

How are simulation conceptual models created in the context of supply chain applications? What is the specification of a simulation conceptual modelling methodology for evaluating supply chain problems?

A review of existing conceptual modelling practice in the context of SCM addressed question one

(detailed in the first stage of the methodological programme, chapter four). As reported in

section 9.1 the chapter identified the scope of research contributions that could be evaluated in

the context of SCM. The majority of the literature identified was written in general for the entire

220

simulation project. The contributions had to be evaluated to identify the applicability of the

principles, advice/methods of simplification; representation and documentation methods and

how a conceptual model can be validated for the conceptual modelling stage. The latter proved

to be demanding as little discussion considered validation at the conceptual modelling stage. This

was surprising as ‘model validation’ is extensively discussed and methods are well known and

widely used. This is compounded by many publications citing the importance of validating a

conceptual model but has not been addressed in any detail. It could be argued that this could be

a secondary contribution in its own right. However, it is suggested in this thesis that this is an area

that should receive substantial attention by researchers in future work.

The required specification for a SCM2 was documented to address the second research question

(detailed in the second stage of the methodological programme, chapter five). The outcome of

this discussion has been summarised in section 9.1.4.2. The objective was achieved by

considering firstly the existing discussions in the conceptual modelling literature, which lacked

breadth and depth. The wider literature on simulation modelling proved more fruitful and could

be evaluated to identify what was applicable for the conceptual modelling stage. These

discussions were novel and useful when designing the SCM2. In order to satisfy the need to

identify the requirements for developing a good methodology the wider OM and SCM literature

needed to be reviewed. The rationale for this was that no methodologies exist for conceptual

modelling and, even when looking at frameworks, they have been developed from the modeller’s

experience with no extensive testing or initial evaluation. The final requirement included the

identification of the set of requirements for conceptual modelling in a SCM context. This was

noted as an original area due to a lack of discussion in the literature. This is classified under the

heading of identifying the range of supply chain improvements, supply chain performance within

the setting of a supply problem. This was achieved by reviewing the SCOR model to extract the

necessary information for two typical supply problems synthesised from five publications that had

evaluated supply chain problems.

9.2.2 Objective two: Development of SCM2 addressing the specification

The second objective concerns the development of the methodology to create simulation

conceptual models for supply chain applications. This objective is realised in chapter six (stage III:

Outline design for the SCM2) and chapter seven (Stage IV: detailed design for SCM2) and evaluated

against the required specification presented in chapter five. The question that is answered in this

thesis to achieve objective two asks:

Can a simulation conceptual modelling methodology be developed to meet the required specification?

221

Firstly, stage three of the methodological programme provides an outline design for the SCM2.

The design of the methodology is underpinned by the conceptual base established by objective

one discussed in the previous section (addressed in stage I: Review of existing conceptual

modelling practice in SCM, chapter four, and Stage II: Required specification for a SCM2, chapter

five). The design issues for each of the requirements identified in chapter five are considered in

detail to identify the key concepts to be incorporated into the SCM2. At the core of the discussion

is how domain knowledge can be utilised to enable a more efficient and focused methodology. It

is argued that SCOR presents a number of benefits to extract information and use standard

terminology for describing a supply problem. The key concepts are aligned to the general stages

of a conceptual modelling project in order to identify an outline process specific to the needs of

supply chain applications.

Secondly, the outline design is further detailed and refined in stage four of the research

programme. This is achieved by applying the outline design presented in chapter six to two

typical and representative SCM applications. The aim was to incorporate the key concepts into

the phases specified for the purposes of conceptual modelling in the context of supply chain

problems. These are justified from a discussion of how each step and key concept can be applied

to the two case applications; observations are detailed in appendix A. The proposed methodology

is evaluated against the required specification to show that the requirements had been met

before proceeding to the preliminary validation in chapter eight.

9.2.3 Objective three: Preliminary validation of the SCM2

The final objective of this thesis preliminarily validates the initial ‘feasibility’ and ‘utility’ of the

detailed and refined methodology. These two criterions were identified in section 3.2.6 and

expanded upon in section 8.3 to establish a set of sub-criteria that could be used to evaluate the

SCM2. The objective is realised in chapter 8, corresponding to the final stage of the

methodological programme addressed in this thesis (stage five: Preliminary validation of the

SCM2). The question posed to address objective three was:

Can the methodology be followed (feasibility) and aid a user (utility) to create a simulation conceptual model for a SCM application?

The evaluation of the feasibility showed that the methodology could be followed to describe the

actual practices to be included in the model. It was found that there was sufficient information

required and provided by the steps to complete them successfully. Table 8.8 showed that the

information required was the clarity of terms and means of communication; describing the

222

objectives; describing the improvements; describing the inputs and interconnections in the

model; deciding what to include in the model and to identify and describe actual practice.

The evaluation of the methodology utility demonstrated that the methodology aids a user to

describe useful and relevant set of actual practices to be included in the computer model. The

outcome from the methodology was applicable for the purpose at hand – it satisfied the

requirement to describe the actual practices to be represented in the model. A comparison

between the outcome from the methodology and the actual computer model (how the actual

practices to be represented by the model components and their relationships) presented in Taylor

et al., (2008) showed there were no significant omissions. However, there were some differences

in how the actual practices were implemented. To an extent, this can be expected as the actual

practices are represented by the model components and their relationships from the perspective

of the modeller. The significance of this is that the methodology was more comprehensive and

rigorous in its approach. It facilitated the decisions made on the model content, documentation

and validation of the conceptual model. It can be suggested that the decisions made regarding

the ‘shipping delay’ in the Taylor et al., (2008) warrant further explanation and consideration of

the impact of delivery practices on the model (e.g. sensitivity analysis). A number of issues were

also identified corresponding to the facilitation of the methodology and were addressed in the

discussion of opportunities to improve the SCM2 (C.f. section 8.7).

9.3 Limitations of study

There are a number of limitations of this study that were outlined and evaluated to determine any

areas that require further work. The main limitations include the tautological criticisms that are

presented by the nature of the research programme. This includes that the SCM2 has only been

refined and initially validated in three case study applications, using secondary data and applied

by the actual researcher. A review of existing methodological approaches and key issues in the

development and validation of a methodology suggested this is favourable in comparison to other

similar published work. It is not possible to declare that the SCM2 is ‘generalisable’ although it can

be suggested that it does commend ‘literal replication’.

This thesis claims that scientific knowledge has been developed on how to use domain-knowledge

with a procedure for simulation conceptual modeling for SCM applications. It cannot be claimed

that theory has been developed as this would involve further iterations through the normal cycle

of research as described by Meredith (1993). This includes continual iteration from description,

to explanation, to testing. The research programme was justified to firstly develop a strong

223

conceptual base for an outline design for a SCM2 after an extensive literature review on existing

practice and identification of the SCM2 required specification. Secondly, develop and finally

validate the SCM2 using secondary data from three existing cases.

In order to develop theory, Meredith (1993) suggests the SCM2 needs to be tested against reality

until they are eventually developed into theories as research study builds upon research study.

Each iteration through the research cycle adds confidence to previous findings or will force the

researcher to refine the methodology and thus develop more valid and complete theory

(Meredith, 1993). This research has demonstrated that the SCM2 has initial feasibility and utility

but the next stage requires rigorous testing. To remedy these limitations further work should

include:

Application of the methodology in different industrial contexts with primary data

(discussed in section 9.3.1)

Use actual participants to follow the methodology as it is prescribed (discussed in section

9.3.2).

Further applications are required to build upon the initial validation of the feasibility and

utility and to validate that the methodology is usable (discussed in section 9.3.3)

Table 9.3 summarises the issues for future testing presented in section 8.6 for each criterion and

need to apply to different contexts and participants.

Table 9.315 Summary of issues for future testing

Issue for future testing Related test

criteria Need to apply in different contexts

Need to use different facilitators and

participants

How different facilitators utilise the domain knowledge provided by SCOR

Feasibility - Yes, does SCOR enable a

more efficient and focused process?

Test how different participants are involved in each step

Feasibility Yes, different contexts required Yes, different participants

required

Test how the information provided to draft a conceptual model is used at the final validation phase

Feasibility Yes, different contexts required Yes, how different

participants make use of information

Relevance of the methodology to create a conceptual model that is more valid and credible

Utility Yes, can the procedure be repeated? -

The usefulness of following a structured approach as opposed to no formal methods

Utility Yes, Is the output provided from the SCM2 more complete and accurate?

Yes, from a users perspective

Identify from the participants whether any problems arose or need to be addressed when using the methodology

Utility Yes, what issue arises in different

contexts? Yes, from a users

perspective

The methodology is clear as it is well structured and detailed

Usability - Yes, from a users

perspective

The methodology should be used by both experts and benefit novice users

Usability - Yes, test with experts and

novice users

The methodology is appropriate but can be improved to reduce time consuming activities

Usability Yes, identify opportunities to improve

the facilitation of the methodology (C.f. section 8.6.3)

-

224

9.3.1 Application in different industrial contexts with primary data

The SCM2 has been applied in three different supply chain applications representing typical types

of supply problems using existing cases (i.e. secondary data). These include a simplified beer

supply chain of five actors in a chain used as a teaching and often as a research case, an

industrially rich and complex automotive seat supply chain and a dyadic coffeepot supply chain

with geographical constraints. Each of the cases offered a different set of circumstances

representing different levels of complexity and detail.

The actual SCM2 needs to be applied to a range of supply chain problems from differing industrial

contexts to be able to generalise and to claim its completeness. The research presented in this

thesis has relied upon secondary data and not original cases. Hence, there is a need to observe

actual participants using primary data. The utilisation of the Supply Chain Council does improve

the relevance, correctness, economic efficiency and clarity of the domain knowledge used in the

process of conceptual modelling. This is a separate issue but it has been argued in this thesis that

using domain knowledge can potentially enable a more efficient and focused process. The Supply

Chain Council covers five special interest groups: aerospace and defence, automotive, electronics,

retail and consumer packaged goods and pharmaceuticals. Further work would need to

concentrate on the application of the actual methodology in each of these application areas with

a range of representative problems.

9.3.2 Use of different facilitators (potential users) to follow the SCM2

The methodology has been developed and validated by the researcher as the main facilitator

following the steps in the methodology. It was argued that this is necessary to ensure consistency

in application and the primary focus should to be to demonstrate it has initial feasibility and has

utility. Questions regarding the reflexivity and bias of the researcher were discussed in section

3.3.1; issues were minimised by using existing case data that has been collected from a range of

sources and methods. In addition to this, the output from the methodology was compared with a

published computer simulation model. Future work will require a number of potential users (e.g.

expert modellers, novice modellers such as students) to be trained to use the SCM2. The

researcher in this instance should observe and use feedback to further refine and validate the

methodology.

The output generated from the methodology is useful and relevant and the use of SCOR in the

process of conceptual modelling has been shown to potentially enable a more efficient and

focused approach. The methodology at present requires ‘expert facilitation’ but its particular

value will be in improving the teaching and practice of conceptual modelling with novice users.

225

Further work is required to identify opportunities to improve the facilitation of the methodology

and to observe how expert and novice users can benefit from the approach in comparison to not

following any structured methods and approaches at all.

9.3.3 Validation of the usability of the SCM2

Section 8.6.3 notes that the thesis does not claim that the SCM2 has been validated against the

‘usability’ criteria. It was noted that this would involve observing actual participants to address

the question of how easily the methodology as prescribed could be followed. Although, the three

applications from the perspective of the facilitator identified three areas summarised in table 8.11

that should be the primary focus for future tests. This includes the clarity and structure; how time

can be reduced in each of the stages and observations with both expert and novice users. To an

extent, ‘usability’ is considered as a major area to improve the facilitation of the SCM2. This can

be achieved by embedding the methodology in a web-based application coupled with the SCOR

domain knowledge. This will aid in the facilitation of the analysis and in areas automate the

process (e.g. identification of candidate process elements).

9.4 Implication for further research and practice

The primary and secondary contributions made in this thesis have implications for research and

practice within the context of conceptual modelling and in other related fields. Using Robinson’s

(2006) discussion of issues in conceptual modelling, it can be demonstrated how this research has

made significant and relevant advances in the field, and provides avenues for further work (shown

in table 9.4).

The research presented in this thesis has made a number of significant advances for each of the

issues noted in table 9.4. It has been noted that there is little guidance on conceptual modelling.

Reviewing the issues noted by Robinson (2006a; 2006b) indicates that this is a significant and

comprehensive study on conceptual modelling in general and specifically for the SCM domain.

This also includes the applicability of general discussions in the modelling literature to the

conceptual modelling stage. The thesis has contributed to advancing a definition for conceptual

modelling, in particular in the context of SCM (e.g. utilising domain knowledge). A methodology

has been developed which is underpinned by existing practice including modelling principles,

methods of simplification and a procedure to follow for conceptual modelling of SCM

applications. It also includes steps in the procedure to build valid and credible models and a final

validation stage. The output from the methodology delivers a conceptual model using suitable

methods for representation and communication.

226

Table 9.416 Revisiting Robinson (2006a; 2006b) issues in CM Issue in conceptual modelling

(Robinson, 2006) Advance made in this

thesis Opportunity for further work

Developing consensus over the definition of a conceptual model/conceptual modelling

Yes, in SCM context

Synthesis and critique of existing contributions in the literature has presented some clarity on what constitutes a conceptual model in particular for SCM applications. Opportunity exists to use the definitions provided for research, teaching and practice.

Identifying the requirements for a conceptual model

Yes, in SCM context

First research to present the requirements for conceptual modelling for SCM applications. This may have implications for other domains. It was argued that domain knowledge is key to conceptual modelling and this will shape the process. There is an opportunity to identify common stages for conceptual modelling and to extend the methodology for other domains (e.g. manufacturing, military applications)

Development of methods for designing conceptual models including modelling principles, methods of simplification and modelling frameworks

Key concepts and process in SCM context

Synthesis and critique of existing contributions may lead to consensus of the different approaches to conceptual modelling. The key concepts are unique and novel; they have presented new opportunities to identify principles and methods applicable to conceptual modelling. These opportunities could be extended to other domains and in general.

Moving towards standard methods for representing and communicating a conceptual model

Yes, spreadsheet application proposed (using automation)

Methods have been considered in a SCM context, but more so. a standard method using a spreadsheet application has been proposed which can be further enhanced into a web-based application using automation between steps. The intention is to further increase the usability of the methodology. Further work should also concentrate on how process reference models can be used and enhanced for use in a conceptual modelling project.

Developing procedures for validation of a conceptual model

Yes, embedded in SCM2. The discussions of applicable methods are made in general.

Synthesis and critique of existing contributions may lead to consensus in validating conceptual models. A ‘hypothesis test’ and ‘expert review’ has been argued as the only existing methods for validating a conceptual model. This has been noted as an area for considerable scope and of importance to the simulation community.

Investigating effective means for teaching the art of conceptual modelling

Development of a methodology that synthesises existing approaches to conceptual modelling

Yes, methodology is intended to aid novice and expert users in a SCM context. The work provides a comprehensive study of existing practice that is applicable at the conceptual modelling stage. The ideas presented in this thesis can be used for teaching of conceptual modelling

Table 9.4 presents a number of opportunities to extend the SCM2 and provide avenues for further

study. It is anticipated that extending this research will improve the accessibility of the SCM2 to a

wider audience, teaching and application of conceptual modelling in practice and improve the

rigour of simulation studies. The issues identified that concerned the limitations of SCOR have

implications more generally for researchers and practitioners who wish to use SCOR for

simulation purposes. More generally, the implication for wider research, centres on defining

what constitutes a conceptual model for different domains, process for creating a conceptual

model and identifying existing and new principles and methods that are applicable at the

conceptual modelling stage of a simulation project. Building upon Robinson (2006a; 2006b)

issues, the opportunities for further research can be refined in the context of what has been

delivered by this thesis:

Acceptance of what constitutes a conceptual model and their requirements – The work

contributes to gaining a consensus on a definition for conceptual modelling. These have

been proposed in general but the content of a model is specific to a particular domain.

Future research should focus on the domain requirements for conceptual modelling.

227

Identify principles and methods specific to the conceptual modelling stage – The work

suggests some key concepts for conceptual modelling for SCM applications. The

literature has focused upon modelling principles and methods, but opportunities exist to

identify those that are applicable to conceptual modelling and to develop new principles

and methods for conceptual modelling.

Advance further how domain knowledge can be used in the process of conceptual

modelling – It was argued that domain knowledge is key to the process of conceptual

modelling and that a process reference model is useful. Although, SCOR has been used

widely for simulation, there are many opportunities to extend SCOR so that its utility for

simulation purposes can be improved. This includes in the detailed descriptions offering

advice for the potential modeller and identifying the interconnections between practices,

processes and metrics between supply chain actors.

Gain consensus on the purpose and methods for validating a conceptual model – This

was noted of significance importance. Although this was embedded into the procedure,

an opportunity exists to research more general validation methods and a procedure for

conceptual modelling

Identifying ways to extend and facilitate the methodology – Opportunities to improve

the SCM2 were presented in section 8.7. These were identified as the role and impact of

automating certain steps in the methodology, strengthening the utilisation of SCOR to

provide domain knowledge for conceptual modelling, and developing a web-based tool

that can facilitate the methodology.

9.5 Chapter summary

The primary contribution presented in this thesis is the ‘development, refinement and preliminary

validation of a methodology that utilises domain-knowledge combined with a procedure that can

be followed to create a simulation conceptual model for SCM applications’. The methodology at

its heart incorporates into its design a set of ten key concepts that utilise domain-knowledge with

a procedure for conceptual modelling of supply chain problems. The methodology has been

preliminarily validated, and evaluated, to demonstrate that it is initially feasible and has utility.

Other notable advances include an examination of existing simulation conceptual modelling

practice and a specification of the requirements for simulation conceptual modelling. A

discussion of the research issues in conceptual modelling in SCM demonstrated that these

contributions are both a significant and relevant area for research.

228

The primary contribution and other advances made by this thesis were arrived at by forming,

outlining, detailing and preliminarily validating the SCM2. A five stage methodological programme

was adopted to address the research aims and explore each research question using an iterative

triangulation method. This included reviewing existing conceptual modelling practice to establish

the need for a SCM2 (stage I, chapter 4), form the specification for the SCM2 (stage II, chapter 5),

outline design for the SCM2 (stage III, chapter 6), detailed refinement design of the SCM2 (stage IV,

chapter 7) and a preliminary validation of the SCM2 (stage V, chapter 8).

The limitations of this research have been identified, along with some future avenues and

implications for both research and practice. The primary limitation lies in the number of

refinement and applications in different industrial contexts, involvement of different facilitators

and participants and the need to evaluate the ‘usability’ of the SCM2. There is a need for rigorous

testing with a full range of original case-study applications to extend the initial 'feasibility' and

'utility' validation and evaluate the SCM2 'usability’. This is important as the thesis has presented

three development and validation applications, to demonstrate confidence in the evaluation

criteria but further applications are necessary to build eventual theory. This will involve actual

users (both expert and novice simulation users) to evaluate how the methodology is to be used in

practice, without bias from the researcher, and to obtain feedback to refine the SCM2 further.

There are a number of implications to both extend the SCM2 (e.g. develop a web-based

application), and to provide further avenues of study (e.g. strengthen SCOR for the purpose of

conceptual modelling, teaching and practice of conceptual modelling).

229

References

ACKERE, A.V., LARSEN, E.R. and MORECROFT, J.D.W. (1993) Systems thinking and business process redesign: an application to the beer game. European Management Journal, 11(4), pp. 412-423.

AGARWAL, A. and SHANKAR, R. (2002) Analysing alternatives for improvement in supply chain performance. Work Study, 51(1), pp. 32-37.

AGERFALK, P, J., ERIKSSON, O., (2004) Action-oriented conceptual modelling, European Journal of Information Systems, 13(1), pp. 80 – 92.

ALBORES, P., BALL, P.D. and MACBRYDE, J.C. (2002) Assessing the impact of electronic commerce in business processes: A simulation approach. IN: Operations Management and the New Economy Proceedings of 9th International European Operations Management Conference. Copenhagen Business School, 2-4 June, Denmark Copenhagen: pp. 15-26.

ALBORES, P., LOVE, D., WEAVER, M., STONE, J. and BENTON, H. (2006) An evaluation of SCOR modelling tools and techniques. IN: BENNETT, D., CLEGG, B., GREASLEY, A., and ALBORES, P. (eds) Technology and Global Integration: Proceedings of the Second European Conference on the Management of Technology, 2006, Aston Business School, Birmingham, UK, pp. 16-24.

ALFIERI, A. and BRANDIMARTE, P. (1997) Object-oriented modeling and simulation of integrated production/distribution systems. Computer Integrated Manufacturing Systems, 10(4), pp. 261 – 266.

ALGUIRE, M.S., FREAR, C.R. and METCALF, L.E. (1994) An Examination of the Determinants of Global Sourcing Strategy. Journal of Business & Industrial Marketing, 9(2), pp. 62-74.

ALLWOOD, J.M. and LEE, J.H. (2005) The design of an agent for modelling supply chain network dynamics. International Journal of Production Research, 43(22), pp. 4875 – 4898.

AKKERMANS, H.A. (2001) Emergent Supply Networks: System Dynamics Simulation of Adaptive Supply Agents. IN: 34th Hawaii International Conference on System Sciences, 3-6 January 2001, Maui, Hawaii: IEEE.

ANDERSON, D.F., RICHARDSON, G.P. and VENNIX, J.A.M. (1997) Group model building: adding more science to the Craft. System Dynamics Review, 13(2), pp. 187-201.

ANDERSON, E.G., FINE, C. H. and PARKER, G. G. (2000) Upstream volatility in the supply chain: The machine tool industry as a case study. Production and Operations Management, 9(3), pg. 239 – 261.

ANDERSON, E.G. and MORRICE, D.J. (2000) A simulation game for teaching service-orientated supply chain management: Does information sharing help managers with service capacity decisions? Production and Operations Management Society, 9(1), pp. 40 – 55.

ANGERHOFER, B.J. and ANGELIDES, M.C. (2000) System dynamics modelling in supply chain management: Research review, IN: JOINES, J.A., BARTON, R.R., KANG, K. and FISHWICK, P.A. (eds) Proceedings of the 2000 Winter Simulation Conference. Orlando, Florida, 2000. SCSI, pp. 342-351.

APAIAH, K.R. (2006) Designing food supply chains: a structured methodology. (PhD) Netherlands, Wageningen University.

APPELQVIST, P. and GUBI, E. (2005) Postponed variety creation: case study in consumer electronics retail. International Journal of Retail & Distribution Management, 33(10), pp. 734-48.

APTE, U.M. and VISWANATHAN, S. (2000) Effective cross docking for improving distribution efficiencies. International Journal of Logistics, 3(3), pp. 291 – 302.

230

ARNS, M., FISCHER, M., KEMPER, P. and TEPPER, C. (2002) Supply chain modelling and its analytical evaluation. Journal of the Operational Research Society, 53, pp. 885-894.

ASHAYERI, J. and KEIJ, R. (1998) Global business process re-engineering: a system dynamics based approach. International Journal of Operations and Production Management, 18(9/10), pp. 817-831.

ATES, A., (2008) Fundamental concepts in management research and ensuring research quality: Focusing on case study method, 8th Annual European Academy of Management Conference, Slovenia, 14 – 17 May.

AUERBACH, C. F., and SILVERSTEIN, L. B., Qualitative data: An introduction to coding and analysis, New York: New York University Press.

BAILY, P. and FARMER, D. (1985) Purchasing principles and management. Harlow: Pearson.

BAINES, T.S. (1994) Modelling in the evaluation of a manufacturing strategy. (PhD) Cranfield University.

BAINES, T.S. and KAY, J.M. (2002) Human Performance Modelling as an aid in the Process of Manufacturing System Design: a Pilot Study. International Journal of Production Research, 40(10), pp. 2321-2334.

BALCI, O. (1986) Credibility assessment of simulation results: The state of the art. IN: WILSON, J, R., HENRIKSEN, J, O. and ROBERTS, S, D. (eds) Proceedings of the 1986 Winter Simulation Conference. Washington, D.C., 1986. ACM, pp. 38 – 44.

BALCI, O. (1994) Validation, verification, and testing techniques throughout the life cycle of a simulation study. Annals of Operations Research, 53(1), pp. 121-173.

BALCI, O. (1997) Verification, validation, and accreditation of simulation models. IN: ANDRADÓTTIR, S., HEALY, K.J., WITHERS, D.H. and NELSON, B.L. (eds) Proceedings of the 29th conference on Winter simulation. Atlanta, Georgia, 7-10 December 1997. IEEE, pp. 135-141.

BALCI, O. and NANCE, R.E. (1985) Formulated problem verification as an explicit requirement of model credibility. Simulation, 45(2), pp. 76-86.

BALCI, O., NANCE, R.E., ARTHUR, J.D. and ORMSBY, W.F. (2002) Expanding our horizons in verification, validation, and accreditation research and practice. IN: PETERS, B. A., SMITH, J. S., MEDEIROS, D. J. and ROHRER, M. W. (eds) Proceedings of the 2001 Winter Simulation Conference. San Diego, CA, 8-11 December 2002. IEEE, pp. 653-663.

BALL, P., ALBORES, P. and MACBRYDE, J. (2004) Requirements for modelling e-business processes. Production Planning and Control, 15(8), pp. 776-785.

BALL, P., LOVE, D. and ALBORES, P. (2008) Financial evaluation in supply chain design using enterprise simulation, IN: Proceedings of the Production and Operations Management Society Conference. La Jolla, CA, 9-12 May 2008.

BAGCHI, S., BUCKLEY, S.J., ETTL, M. and LIN, G.Y. (1998) Experience using the IBM supply chain simulator. IN: MEDEIROS, D.J., WATSON, E.F., CARSON, J.S. and MANIVANNAN, M.S. (eds), Proceedings of the 1998 Winter Simulation Conference. Washington, D.C., 1998. IEEE, pp. 1387-1394.

BANDINELLI, R. RAPACCINI, M. TUCCI, M. and VISINTIN, F. (2006) Using simulation for supply chain analysis: reviewing and proposing distributed simulation frameworks. Production Planning and Control, 17(2), pp. 167-175.

BANKS, J. (1991) Selecting simulation software. IN: NELSON, B.L., KELTON, W.D., CLARK, G.M. (Eds) Proceedings of the 1991 Winter Simulation Conference. Phoenix, Arizona, 8-11 December 1991. pp. 15-21.

231

BANKS, J. (ed) (1998) Handbook of simulation principles, methodology, advances, applications, and practice. USA: John Wiley & Sons.

BANKS, J. (1999) Introduction to simulation. IN: FARRINGTON, P.A., BLACK NEMBHARD, H., STURROCK, D.T. and EVANS, G.W. (eds) Proceedings of the 1999 Winter Stimulation Conference. Phoenix, Arizona 1999. AGM, pp. 7-13.

BANKS, J., BUCKLEY, S., JAIN, S. and LENDERMANN, P. (2002) Panel session: opportunities for simulation in supply chain management. IN: YÜCESAN, E., CHEN, C.H., SNOWDON, J.L. and CHARNES, J.M. (eds) Proceedings of the 2002 Winter Simulation Conference. San Diego, CA, 8-11 December 2002. WSC, pp. 1652–11658.

BANKS, J., CARSON II, J.S., NELSON, B.J. and NICOL, D.M. (2005) Discrete-event system simulation, 4th edition. New Jersey, USA: Prentice-Hall Inc.

BANKS, J., GERSTEIN, D. and SEARLES, S. P. (1988) Modeling processes, validation, and verification of complex simulations: a survey. Methodology and Validation, Simulation Series, 19(1), pp. 13-18.

BARNETT, M. W., and MILLER, C. J. (2000) Analysis of the virtual enterprise using distributed supply chain modeling and simulation: An application of e-SCOR. IN: JOINES, J. A., BARTON, R. R. KANG, K. and FISHWICK, P. A. (eds) Proceedings of the 2000 Winter Simulation Conference. Orlando, Florida 2000. SCSI, pp. 352–355.

BEACH, R., MUHLEMANN, A.P., PRICE, D.H.R., PATERSON, A., SHARP, J.A., The role of qualitative methods in production management research, International Journal of Production Economics, 74(1-3), pp. 201 – 212.

BEAMON, B. M. (1998) Supply chain design and analysis: Models and methods. International Journal of Production Economics, 55(3), pp. 281-294.

BEAMON, B. M. (1999) Measuring supply chain performance. International Journal of Operations & Production Management, 19(3), pp. 275-292.

BEAMON, B. M. and CHEN, V.C.P. (2001) Performance analysis of conjoined supply chains. International Journal of Production Research, 39(14), pp. 3195-3218.

BEECH, N., (2005) Research Methodology Course Notes: Strathclyde Business School.

BECKER, J., KUGELER, M. and ROSEMANN, M. (2003) Process Management – A guide for the design of business processes. Berlin: Springer-Verlag.

BENBASAT, I., GOLDSTEIN, D, K., and MEAD, M. (1987) The case research strategy in studies of information systems. MIS Quarterly, (11)3, pp. 369-386.

BENNETT, D. and FORRESTER, P. (1993) Market-focused production systems: design and implementation. Hemel Hempstead: Prentice Hall.

BENTON, H. (2009) A process framework for selecting supply chain system architecture in manufacturing supply chain and networks. (Phd) Birmingham: Aston University.

BERRY, D., TOWILL, D.R. and WADSLEY, N. (1994) Supply chain management in the electronics product industry. International Journal of Physical Distribution & Logistics Management, 24(10), pp. 20-32.

BHASKARAN, S. (1998) Simulation analysis of a manufacturing supply chain. Decision Sciences, 29(3), pp. 633-657.

BINDER, M., and EDWARDS, J, S., (2008) Using grounded theory method for theory building in operations management research: A study on inter-firm relationship governance, International Journal of Operations and Production Management, 30(3), pp. 232 – 259.

232

BISWAS, S. and NARAHARI, Y. (2004) Object oriented modeling and decision support for supply chains. European Journal of Operational Research, 153(3), pp. 704-726.

BITITCI, U. S., MENDIBIL, K., MARTINEZ, V. and ALBORES, P. (2005) Measuring and managing performance in extended enterprises. International Journal of Operations and Production Management, 25(4), pp. 333-353.

BLACKHURST, J., WU, T. and O'GRADY, P. (2005) PCDM: a decision support modelling methodology for supply chain, product and process design decisions. Journal of Operations Management, 23(3-4), pp. 325-343.

BLACKWELL, P. (2003) A decision making methodology for integrating information systems within SMEs. (PhD) Cranfield University.

BOLSTORFF, P. and ROSENBAUM, R. (2003) Supply chain excellence: A handbook for dramatic improvement using the SCOR model. New York: AMACOM American Management Association.

BOWERSOX, D.J., CLOSS, D.J. and STANK, T.P. (1999) 21st century logistics: Making supply chain integration a reality. Oak Brook, IL: Council of Logistics Management.

BROOKS, R. (2006) Some thoughts on conceptual modelling: performance, complexity and simplification. IN: ROBINSON, S., TAYLOR, S., BRAILSFORD, S. and GARNETT, J. (eds) Proceedings of the 2006 OR Society Simulation Workshop, 28-29 March 2006.

BROOKS, R. (2007) Conceptual modelling: framework, principles, and future research, Lancaster University Management School Working Paper, 2007/011.

BROOKS, R.J. and TOBIAS, A.M. (1996) Choosing the best model: Level of detail, complexity, and model performance. Mathematical and Computer Modelling, 24(4), pp. 1-14.

BROOKS, R.J. and TOBIAS, A.M. (1999) Methods and benefits of simplification in simulation. IN: AL-DABASS, D. and CHENG, R.C.H. (eds) UKSim 99 Fourth National Conference of the U.K. Simulation Society. St Catarines College, Cambridge, 7–9 April 1999. UK Simulation Society, pp. 88–92.

BROOKS, R.J. and TOBIAS, A.M. (2000) Simplification in the simulation of manufacturing systems. International Journal of Production Research, 38(5), pp. 1009-1027.

BRYMAN, A. and BELL, E. (2007) Business research methods second edition. Oxford: Oxford University Press.

CADDICK, J.R. and DALE, B.G. (1987) Sourcing from less developed countries: A case study. Journal of Purchasing and Materials Management, 23(3), pp. 17-24.

CANEZ, L.E., PLATTS, K.W. and PROBERT, D.R. (2000) Developing a framework for make-or-buy decisions. International Journal of Operations & Production Management, 20(11), pp.1313-1330.

CARSON, J. S. (1986) Convincing users of model’s validity is challenging aspect of modeller’s job. Industrial Engineering, 18(6), pp. 74 – 85.

CARSON II, J.S. (2002) Model verification and validation. IN: YUCESAN, E., CHEN, C.-H., SNOWDON, J.L. and CHARNES, J. M. (eds) Proceedings of the 2002 Winter Simulation Conference. 2002. Piscataway, New Jersey: IEEE, pp.52-58.

CARSON II, J.S. (2004) Introduction to modelling and simulation, IN: Proceedings of the 2004 Winter Simulation Conference. Washington, D.C., 5-8 December 2004. WSC, pp. 9-16.

CAVALIERI, S., CESAROTTI, V. and INTRONA, V. (2003) A Multiagent Model for Coordinated Distribution Chain Planning. Journal of Organizational Computing and Electronic Commerce, 13(3&4), pp. 267-287.

233

CHAN, F.T.S. and CHAN, H.K. (2005) Simulation modelling for comparative evaluation of supply chain management strategies. The International Journal of Advanced Manufacturing Technology, 25(9-10), pp. 998-1006.

CHAN, F. T. S. and QI, H. J. (2003) An innovative performance measurement method for supply chain management. Supply Chain Management: An International Journal, 8(3), pp. 209-223.

CHANDRAPRAKAIKUL, W. (2008) Strategic positioning within global supply chains. (PhD) Cranfield University, UK.

CHANG, Y. and MAKATSORIS, H. (2001) Supply chain modeling using simulation. International Journal of Simulation, 2(1), pp. 24–30.

CHANG, TI-H., FU, H-P., LEE, W-I., LIN, Y. and HSUEH, H-C. (2007) A study of an augmented CPFR model for the 3C retail industry. Supply Chain Management: An International Journal, 12(3), pp.200-209.

CHANGCHIEN, S.W. and SHEN, H-Y. (2002) Supply chain reengineering using a core process analysis matrix and object-oriented simulation. Information & Management, 39(5), pp. 345-358.

CHATFIELD, D.C., HARRISON, T.P., and HAYYA, J.C. (2006) SISCO: An object-oriented supply chain simulation system. Decision Support Systems, 42(1), pp. 422-434.

CHATFIELD, D. C., KIM, J. G., HARRISON, T. P. and HAYYA, J. C. (2004) The bull-whip effect – Impact of stochastic lead time, information quality, and information sharing: A simulation study. International Journal of Production and Operations Management, 13(4), pp. 340-353.

CHECKLAND, P.B. (1981) Systems Thinking, Systems Practice. Chichester: Wiley.

CHECKLAND, P.B. (1999) Soft Systems Methodology in Action, Chichester: Wiley.

CHEN, I.J. and PAULRAJ, A. (2004) Understanding supply chain management: Critical Research and a theoretical framework. International Journal of Production Research, 42(1), pp. 131-163.

CHICK, S.E. (2006) Six ways to improve a simulation analysis, Journal of Simulation, 1, pp. 21–28.

CHOI, T.Y., HONG, Y. (2002) Unveiling the structure of supply networks: case studies in Honda, Acura and Daimler-Chrysler, Journal of Operations Management , 20(5) pp. 469-93.

CHOPRA, S. and MEINDL, P. (2004) Supply chain management: Strategy, planning, and pperation, New Jersey, USA: Prentice-Hall.

CHRISTOPHER, M. (2004) Logistics and supply chain management: Creating value-adding networks. 3rd ed. London: Pearson.

CHRISTOPHER, M. and TOWILL, D.R. (2002) Developing market specific supply chain strategies. International Journal of Logistics Management, 13(1), pp. 1-14.

CHWIF, L., BARRETTO, M.R.P. and PAUL, R.J. (2000) On simulation model complexity. IN: JOINES, J.A., BARTON, R.R., KANG, K. and FISHWICK, P.A. (eds) Proceedings of the 2000 Winter Simulation Conference. Orlando, Florida. SCSI, pp. 449-455.

CHWIF, L., BARRETTO, M.R.P., and SALIBY, E. (2002) Supply chain analysis: Spreadsheet or simulation? IN: YÜCESAN, E., CHEN, C.H., SNOWDON, J.L. and CHAMES, J.M. (eds) Proceedings of the 2002 Winter Simulation Conference. San Diego, CA 2002. WSC, pp. 59-66.

COOPER, M.C., LAMBERT, D.M. and PAGH, J.D. (1997) Supply chain management: More than a new name for logistics. International Journal of Logistics Management, 8(1), pp. 1-14.

CONWAY, R. W. (1963) Some tactical problems in digital simulation. Management Science, 10(1), pp. 47 – 61.

234

COUGHLAN, P. and COGHLAN, D. (2002) Action research for operations management. International Journal of Operations & Production Management, 22(2), pp. 220-240.

COURTOIS, P-J. (1985) On time and space decomposition of complex structures. Communications of the ACM, 28(6), pp. 590-603.

COUSINS, P.D. and SPEKMAN, R. (2003) Strategic supply and the management of inter- and intra-organisational relationships. Journal of Purchasing and Supply Management, 9(1), pp. 19-29.

CROOM, S., ROMANO, P. and GIANNAKIS, M. (2000) Supply chain management: an Analytical Framework for Critical Literature Review. European Journal of Purchasing & Supply Management, 6(1), pp. 67-83.

CROSON, R. and DONOHUE, K., (2005) Behavioural causes of the bullwhip effect and the observed value of inventory information. Management Science, 52(3), pp. 323-336.

CROXTON, K.L., GARCIA-DASTUGUE, S.J., LAMBERT, D.M. and ROGERS, D.S. (2001) The supply chain management processes, International Journal of Logistics Management, 12(2), pp. 13-36.

DATTA, P.P., CHRISTOPHER, M. and ALLEN, P. (2007) Agent-based modelling of complex production/distribution systems to improve resilience. International Journal of Logistics, 10(3), pp. 187-203.

DAVIS, T. (1993) Effective supply chain management. Sloan Management Review, 34(4), pp. 35 – 46.

DENYER, D., TRANFIELD, D., (2006) Using qualitative research synthesis to build an actionable knowledge base, Management Decision, 44(2), pp. 213 – 227.

DE WEERD-NEDERHOF, P.C., (2001) Qualitative case study research. The case of a PhD research project on organising and managing new product development, Management Decision, 39(7), pp. 513 – 538.

DISNEY, S.M. and TOWILL, D.R. (2003a) The effect of vendor managed inventory (VMI) dynamics on the bullwhip effect in supply chains. International Journal of Production Economics, 85(2), pp. 199-215.

DISNEY, S.M. and TOWILL, D.R. (2003b) Vendor-managed inventory and bullwhip reduction in a two-level supply chain. International Journal of Operations and Production Management, 23(6), pp. 625-651.

DISNEY, S.M., NAIM, M.M. and POTTER, A. (2004) Assessing the impact of e-business on supply chain dynamics. International Journal of Production Economics, 89(2), pp. 109 – 118.

Dubin, R. (1978). Theory building (Rev. ed.). New York: Free Press.

DUBOIS, A., ARAUJI, L., (2007) Case research in purchasing and supply management: Opportunities and challenges, Journal of Purchasing & Supply Management, 13(3), pp. 170 – 181.

EDEN, C. and ACKERMAN, F. (2001) SODA— the principles. IN: ROSENHEAD, J., and MINGERS, J. (eds) Rational Analysis for a Problematic World Revisited: Problem Structuring Methods for Complexity. Uncertainty and Conflict. Chichester: Wiley, pp. 21-41.

EISENHARDT, K.M. (1989) Building theory from case study research. Academy of Management Journal, 14(4), pp. 532-550.

EISENHARDT, K. M., (1991) Better stories and better constructs: the case for rigor and comparative logic, Academy of Management Review, 16(3), pp. 620 – 627.

ELLRAM, L.M. (1996) The use of the case study method in logistics research, Journal of Business Logistics, 17(2), pp. 93 – 138.

235

EVANS, A.S. and CLARK, A.N. (1998) Foundations of the unified modelling language. IN: 2nd Northern Formal Methods Workshop, Ilkley, Electronic Workshops in Computing. Springer- Verlag

FAGAN, M.L. (1991) A guide to global sourcing. Journal of Business Strategy, 12(2), pp. 21-26.

FETTKE, P. and LOOS, P. (2003) Classification of reference models – a methodology and its application. Information Systems and e-Business Management, 1(1), pp. 35 -53.

FLIPPINI, R., (1997) Operations management research: some reflections on evolution, models and empirical studies in OM, International Journal of Operations & Production Management, 17(7), pp. 655 – 670.

FIALA P. (2005) Information sharing in supply chains. Omega, 33(5), pp. 419 – 423.

FILDES, R., GOODWIN, P., LAWRENCE, M. and NIKOLOPOULOS, K. (2009) Effective forecasting and judgmental adjustments: an empirical evaluation and strategies for improvement in supply-chain planning. International Journal of Forecasting, 25(1), pp. 3-23.

FINK, A., (2005) How to conduct surveys: A step-by-step guide, 3rd ed., Sage

FISHWICK, P.A. (1995) Simulation model design and execution: Building digital worlds. New Jersey, USA: Prentice-Hall

FORRESTER, J.W. (1961) Industrial dynamics. Cambridge, Mass: M.I.T Press.

FORZA, C., (2002) Survey research in operations management: A process-based perspective, International Journal of Operations & Production Management, 22(2), pp. 152 – 194.

GAN KAI, L.W. (2007) A decision model for manufacturing best practice adoption: Linking practices to competitive strategies. (PhD) Cranfield University, UK.

GARDNER, J.T. and COOPER, M.C. (2003) Strategic supply chain mapping approaches. Journal of Business Logistics, 24(2), pp. 37-64.

GASS, S.I. (1983) Decision-aiding models: Validation, assessment, and related issues for policy analysis. Operations Research, 31(4), pp. 603 – 631.

GATTORNA, J.L. and WALTERS, D.W. (1996) Managing the supply chain: A strategic perspective. New York: Macmillan.

GE, Y., YANG, J.-B., PROUDLOVE, N. and SPRING, M. (2004) System dynamics modelling for supply-chain management: A case study on a supermarket chain in the UK. International Transactions in Operational Research, 11(1), pp. 495-509.

GILMOUR, P. (1998) Benchmarking supply chain operations. Benchmarking: An International Journal, pp. 283-290.

GJERDRUM, J., SHAH, N. and PAPAGEORGIOU, L.G. (2001) A combined optimization and agent-based approach to supply chain modelling and performance assessment. Production Planning and Control, 12(1), pp. 81-88.

GLASER, B. G., STRAUSS, A. L., (1967) The discovery of grounded theory: strategies for qualitative research, Aldine Publishing Co., Chicago.

GOETSCHALCKX, M., VIDAL, C.J. and DOGAN, K. (2002) Modeling and design of global logistics systems: A review of integrated strategic and tactical models and design algorithms. European Journal of Operational Research, 143(1), pp. 1-18.

GREASLEY, A. (2004) Simulation modelling for business. Cornwall: MPG Books Ltd.

GREASLEY, A. (2006) Operations management. Chichester: Wiley.

GUAN, R.L.Y. (2007) Development of a strategic supply chain positioning methodology for SMEs in Singapore. (PhD) Cranfield University, UK.

236

GUNASEKARAN, A. (1999) Agile manufacturing: A framework for research and development. International Journal of Production Economics, 62(1-2), pp. 87-105.

GUNASEKARAN, A., PATEL, C. and TIRTIROGLU, E. (2001) Performance measures and metrics in a supply chain environment. International Journal of Operations & Production Management, 21(1/2), pp. 71-87

GUNASEKARAN, A. and NGAI, E.W.T. (2008) Modelling and analysis of build-to-order supply chains. European Journal of Operational Research, 195(2), pp. 319-334.

GURU, A. and SAVORY, P. (2004) A template-based conceptual modelling infrastructure for simulation of physical security systems. IN: INGALLS, R.G., ROSSETTI, M.D., SMITH, J.S., and PETERS. (eds) Proceedings of the 2004 Winter Simulation Conference. Washington, D.C. 2004. WSC, pp 866–873.

HADDIX, F. (2001) Conceptual modeling revisited: A developmental model approach for modeling and simulation. Proceedings of the 2001 Fall Simulation Interoperability Workshop. Available online.

HAE, L.Y., CHO, M. K., KIM, S. J. and KIM, Y. B. (2002) Supply chain simulation with discrete-continuous combined modelling. Computers & Industrial Engineering, 43(1/2), pp. 375-392.

HAIR, J, F., MONEY, A, H., SAMOUEL, P., and PAGE, M. (2007), Research Methods of Business, John

Wiley & Sons Ltd, Chichester.

HANDFIELD, R.B. and MELNYK, S.A. (1998) The scientific theory-building process: a primer using the case of TQM. Journal of Operations Management, 16(4), pp. 321-339.

HARLAND, C. M. (1996) Supply chain management: relationships, chains, and networks. British Journal of Management, 7(1), pp. 63-80.

HARLAND, C.M. (1997) Supply Chain operational performance Roles. Integrated Manufacturing Systems, 8(2), pp. 70-78.

HARLAND, C.M., LAMMING, R.C. and COUSINS, P.D. (1999) Developing the concept of supply strategy. International Journal of Operations and Production Management, 19(7), pp. 650-674.

HARLAND, C.M., LAMMING, R.C., WALKER, H., PHILLIPS, W.E., CALDWELL, N.D., JOHNSEN, T.E., KNIGHT, L.A. and ZHENG, J. (2006) Supply Management: is it a Discipline? International Journal of Operations & Production Management, 26(7), pp. 730-753.

HEAVEY, C. (2008) Conceptual and process modelling: Analysis in complex simulation environments. UK Operational Research Society Simulation Workshop 2008 (SW08), 1st - 2nd April 2008, Worcestershire, England, UK

HERMANN, C, F. (1967) Critique and comment: Validation problems in games and simulation with special reference to models of international politics. Behavioural Science, 12, pp. 216 – 231.

HERMANN, J.W., LIN, E. and PUNDOOR, G. (2003) Supply chain simulation modeling using the Supply Chain Operations Reference model. IN: Proceedings of the ASME 2003 International Design Engineering Technical Conferences and Computers and Information. Engineering Conference, DETC2003/CIE-48220.

HERON, J., REASON, P., (2001) The practice of co-operative inquiry: Research “with” rather than “on” people. In P. REASON & P. BRADBURY (Eds.), Handbook of action research: Particpative inquiry and practice, pp. 179 – 188, Thousand Oaks, CA: Sage.

HICKS, D. A. (1997) The manager's guide to supply chain and logistics problem solving tools and techniques part I: understanding the techniques. IIE Solutions, 29(9), pp.43-47.

237

HIEBER, R. (2002) Supply chain management: A collaborative performance measurement approach. VDF: Zurich.

HIEBER, R. and HARTEL, I. (2003) Impacts of SCM order strategies evaluated by simulation-based 'Beer Game' approach: the model, concept, and initial experiences. Production Planning and Control, 14(2), pp. 122 – 134.

HIGUCHI, T. and TROUTT, M.D. (2004) Dynamic simulation of the supply chain for a short life cycle product—Lessons from the Tamagotchi case. Computers & Operations Research, 31(7), pp. 1097-1114.

HILL, T. J. (1987) Teaching and research directions in production/operations management: The manufacturing sector. International Journal of Operations & Production Management, 7(4), pp. 5-12.

HINES, P. (1994) Creating world class suppliers: Unlocking mutual competitive advantage, London: Pitman Publishing.

HINES, P. and RICH, N. (1997) Supply-chain management and time-based competition: the role of the supplier association. International Journal of Physical Distribution & Logistics Management, 27(3/4), pp. 210-225.

HO, K., AU, K. and NEWTON, E. (2002) Empirical research on supply chain management: a critical review and recommendations. International Journal of Production Research, 40(17), pp. 4415 – 4430.

HONG, E. and HOLWEG, M. (2005) Evaluating the effectiveness and efficiency of global sourcing strategies, Working paper, Judge Business School, University of Cambridge.

HOLWEG, M. and BICHENO, J. (2002) Supply chain simulation: a tool for education, enhancement and endeavour. International Journal of Production Economics, 78(2), pp. 163-175.

HOLWEG, M., DISNEY, S., HOLMSTRÖM, J. and SMÅROS, J. (2005) Supply chain collaboration: making sense of the strategy continuum. European Management Journal, 23(2), pp. 170-181.

HOLWEG, M. and HELO, P. (2008) Towards a definition of value chain architectures. IN: The 15th Annual EurOMA Conference. Groningen, NL, 15-18 June 2008.

HOULIHAN, J.B. (1987) International supply chain management. International Journal of Physical Distribution and Material Management, 17(2), pp. 51-66.

HUAN, S.H., SHEORAN, S.K. and WANG, G. (2004) A review and analysis of supply chain operations reference (SCOR) model. Supply Chain Management: An International Journal, 9(1), pp.23-29.

HUANG, Z. and GANGOPADHYAY, A. (2004) A simulation study of supply chain management to measure the impact of information sharing. Information Resources Management, 17(3), pp. 20-31.

HUANG, G. Q., LAU, J. S. K. and MAK, K. L. (2003) The impacts of sharing production information on supply chain dynamics: A review of the literature. International Journal of Production Research, 41(7), pp. 1483-1517

HWARNG, H. B., CHON, G, C. S. P., ZIE, N. and BURGESS, T. F. (2005) Modelling a complex supply chain: understanding the effect of simplified assumptions. International journal of production research, 45(13), pp. 2829 – 2872.

IANNONI, A.P. and MORABITO, R. (2006) A discrete simulation analysis of a logistics supply system. Transportation research. Part E, Logistics and transportation review, 42(3), pp.191-210.

INGALLS, R.G. and KASALES, C. (1999) CSCAT: the Compaq supply chain analysis tool, IN: FARRINGTON, P.A., NEMBHARD, H.B., STURROCK, D.T. and EVANS, G.W. (eds) Proceedings of the 1999 Winter Simulation Conference. Phoenix, Arizona, 1999. IEEE, pp. 1201-1206

238

INNIS, G. and REXSTAD, E. (1983) Simulation model simplification techniques, Simulation, 41(1), pp. 7 – 15.

JACOBS, R. (2000) Playing the beer distribution game over the Internet. Production and Operations Management, 9(1), pp. 31-9.

JAMES, K, C. and BHASI, M. (2008) Conceptual modelling of logistic terminals: A framework for classification of models, UK Operational Research Society Simulation Workshop 2008 (SW08), 1st - 2nd April 2008, Worcestershire, England.

JAMMERNEGG, W. and REINER, G. (2007) Performance improvement of supply chain processes by coordinated inventory and capacity management. International Journal of Production Economics, 108(1-2), pp. 183 – 190.

JULKA, N. (2008) An advanced decision process for capacity expansion in manufacturing networks. (PhD), Cranfield University, UK

KAIHARA, T. (2003) Multi-agent based supply chain modelling with dynamic environment. International Journal of Production Economics, 85(2), pp. 263 – 269.

KAMINSKY, P. and SIMCHI-LEVI, D. (1998) A new computerized Beer Game: A tool for teaching the value of integrated supply chain management. IN: LEE, H.L., SHU MING, N.G. (eds) Production and Operations Management Society in POMS Series in Technology and Operations Management. Global supply chain and technology management, Production and Operations Management Society, USA. pp. 216–225.

KANNAN, V. R. and TAN, T. C. (2005) Just in time, total quality management, and supply chain management: understanding their linkages and impact on business performance. Omega, 33(2), pp.153-162.

KASI, V. (2005) Systemic assessment of SCOR for modeling supply chains. Proceedings of the 38th Hawaii International Conference on Systems Science. 3 – 6 January 2005. IEEE, pp 87b.

KELLEY, M. R., (1986) Programmable automation and the skill question: a reinterpretation of the cross-national evidence, Human Systems Management, 6(3), pp. 223 – 241.

KELTON, W. D., SADOWSKI, R. P. and SADOWSKI, D. A. (1998) Simulation with Arena. Singapore: McGraw-Hill.

KIM, C., TANNOCK, J., BYRNE, M., FARR, R., CAO, B. and ER, M. (2004) State-of-the-art review: Techniques to model the supply chain in an extended enterprise. VIVACE WP2.5, Nottingham, England: University of Nottingham, Operations Management Division.

KIMBROUGH, S,O., WU, D.J. and ZHONG, F. (2002) Computers play the beer game: can artificial agents manage supply chains? Decision Support Systems, 33(3), pp. 323 – 333.

KLEIJNEN, J.P.C. (1980) Computers and Profits: Quantifying financial benefits of information, Reading, MA: Addison-Wesley.

KLEIJNEN, J.P.C. (1995) Verification and validation of simulation models. European Journal of Operational Research, 82(1), pp. 145 – 162.

KLEIJNEN, J.P.C. (1999) Validation of models: statistical techniques and data availability. IN: FARRINGTON, P.A., BLACK NEMBHARD, H., STURROCK, D.T. and EVANS, G.W. (eds) Proceedings of the 1999 Winter Simulation Conference. Phoenix, Arizona (1999). IEEE, pp. 647-654.

KLEIJNEN, J.P. C. (2005) Supply chain simulation tools and techniques: a survey. International Journal of Simulation & Process Modelling, 1(1/2), pp. 82–89.

KLEIJNEN, J.P.C. and SMITS, M.T. (2003) Performance metrics in supply chain management. Journal of the Operational Research Society, 54(5), pp. 507-514.

239

KOTIADIS, K., (2007) Using soft systems methodology to determine the simulation study objectives, Journal of Simulation, 1, pp. 215 – 222.

KRAUSE, F, L., LUDDEMAN, J., and STRIEPE, A., (1995), Conceptual modelling for industrial design, CIRP Annals – Manufacturing Technology, 44(1), pp. 137 – 140.

LAMBERT, D. M. and COOPER, M. C. (2000) Issues in supply chain management. Industrial Marketing Management, 29(1), pp. 65-83.

LAMBERT, D. M., COOPER, M. C. and PAGH, J. D. (1998) Supply chain management: Implementation issues and research opportunities. The International Journal of Logistics Management, 9(2), pp. 1-19.

LAMBERT, D.M., GARCA-DASTUGUE, J.S. and CROXTON, K.L. (2005) An evaluation of process-oriented supply chain management frameworks. Journal of Business Logistics. 26(1), pp. 25-51.

LAMMING, R. (1996) Squaring lean supply with supply chain management. International Journal of Operations and Production Management, 16(2), pp. 183-196.

LAMPEL, J. and MINTZBERG, H. (1996) Customizing customization. Sloan Management Review, 38(1), pp. 21– 30.

LARSSON, R., (1993) Case survey methodology: quantitative analysis of patterns across case studies, Academy of Management Journal, 36(6), pp. 1515 – 1546.

LAU, H.C.W., WONG, C.W.Y., PUN, K.F. and CHIN, K.S (2003) Virtual agent modeling of an agile supply chain infrastructure. Management Decision, 41(7), pp. 625-634.

LAW, A.M. (1991) Simulation model’s level of detail determines effectiveness. Industrial Engineering, 23(10), pp. 16 - 18.

LAW, A.M. (2003) Designing a simulation study: how to conduct a successful simulation study. IN: Proceedings of the 35th conference on Winter Simulation. New Orleans, Louisiana, 7- 10 December 2003. WSC, pp. 66-70.

LAW, A.M. (2007) Simulation modelling and analysis, 4th ed. New York: McGraw-Hill Education.

LAW, A.M. (2008) How to build valid and credible simulation models. IN: MASON, S., HILL, R., MONCH, L. and ROSE, O. (eds) Proceedings of the 40th Conference on Winter Simulation. Miami, Florida, 7-10 December 2008. IEEE, pp. 39-47.

LAW, A.M. and KELTON, W.D. (2000) Simulation Modeling and Analysis, 3rd edition. New York: McGraw-Hill.

LAW, A.M. and McCOMAS, M.G. (1986) Pitfalls in the simulation of manufacturing systems. IN: WILSON, J.R., HENRIKSEN, J.O. and ROBERTS, S.D. (eds) Proceedings of the 18th conference on Winter Simulation. Washington, D.C., 8-10 December 1986. ACM, pp. 539-542.

LAW, A.M. and McCOMAS, M.G. (1991) Secrets of successful simulation studies. IN: BARRY, L., NELSON, W., KELTON, D. and CLARK, G.M. (eds) Proceedings of the Winter Simulation Conference. Phoenix, Arizona 1991. IEEE pp. 21-27.

LAW, A.M. and McCOMAS, M.G. (2001) How to build valid and credible simulation models. IN: PETERS, B.A., SMITH, J.S., MEDEIROS, D.J. and ROHRER, M.W. (eds) Proceedings of the 2001 Winter Simulation Conference. 2001. IEEE pp. 22-29.

LEE, N. J., and LINGS, I., (2008) Doing business research. Sage, London.

LEE, W.B., and LAU, H.C.W. (1999) Multi-agent modeling of dispersed manufacturing networks. Expert Systems with Applications, 16(3), pp.297-306.

LEE, H.L., PADMANABHAN, S., and WHANG, S. (1997a) Information distortion in a supply chain: the bullwhip effect. Management Science, 43(4), pp. 546-558.

240

LEE, H.L., PADMANABHAN, S. and WHANG, S. (1997b) The bullwhip effect in supply chains. Sloan Management Review, 38(3), pp. 93-102.

LEHANEY, B. and PAUL. R.J. (1996) The use of soft systems methodology in the development of a simulation of out-patient services at Watford General Hospital. Journal of Operational Research Society, 47(7), pp. 864 – 870.

LEVY, D. (1994) Chaos theory and strategy: Theory, application, and managerial implications. Strategic Management Journal, 15, pp. 167 – 178.

LEWIS, M.W. (1998) Iterative triangulation: a theory development process using existing case studies. Journal of Operations Management, 16(4), pp. 455 – 469.

LI, S., RAGU-NATHAN, B., RAGU-NATHAN, T, S. and SUBBA ROA, S. (2006) The impact of supply chain management practices on competitive advantage and organizational performance. Omega: International Journal of Management Science, 34(2), pp. 107 – 124.

LI, S., SUBBA-RAO, RAGU-NATHAN, T.S. and RAGU-NATHAN, B. (2005) Development and validation measurement instrument for studying supply chain management practices. Journal of Operations Management, 23(6), pp. 618-641.

LITTLE, J.D.C. (1970) Managers and models: The concept of a decision calculus. Management Science, 16(8), pp. 66 – 85.

LIMA, J.B. (2008) Business Process Re-engineering, Supply-chain Integration, Information Technology. (PhD). Salford Universtiy.

LOCKAMY, A. and McCORMACK, K. (2004) The development of a supply chain management process maturity model using the concepts of business process orientation. Supply Chain Management: An International Journal, 9(4), pp. 272-278.

LOU, P., ZHOU, Z-D., CHEN, Y-P. and AI, W. (2004) Study on multi-agent-based agile supply chain management. The International Journal of Advanced Manufacturing Technology, 23(3-4), pp. 197-203

LOWSON, R.H. (2002) Assessing the operational cost of offshore sourcing strategies. International Journal of Logistics Management, 13(2), pp. 13.

LOVE, D.M. (1980) Aspects of design for a spare parts provisioning system. (PhD). Aston University.

MACAL, C.M. and NORTH, M.J. (2005) Tutorial on agent-based modelling and simulation. IN: Proceedings of the 37th Winter Simulation Conference. Orlando, Florida, 4-7 December. WSC pp. 2 – 15.

MALHOTRA, M.K. and GROVER, V., 1998, An assessment of survey research in POM: from constructs to theory, Journal of Operation Management, 16, pp. 407-425.

MARTINEZ V. and ALBORES P. (2003); “Qualitative research in OM: criteria for evaluation”; EUROMA Conference; Lake Como, Italy, June 16-18; Vol. 2 pp 959- 968.

MASON-JONES, R. and TOWILL, D.R. (1997) Information enrichment: designing the supply chain for competitive advantage. International Journal of Supply Chain Management, 2(4), pp. 137-148.

MASON-JONES, R. and TOWILL, D.R. (1999) Total cycle time compression and the agile supply chain. International Journal of Production Economics, 62(1-2), pp. 61-73.

MANUJ, I., MENTZER, J.T. and BOWERS, M.R. (2009) Improving the rigor of discrete-event simulation in logistics and supply chain research. International Journal of Physical Distribution & Logistics Management, 39(3), pp. 172-201

241

MANZINI, RICCARDO, F., EMILIO, G., MAURO, P., ALESSANDRO, R. and ALBERTO (2005) Simulation performance in the optimisation of the supply chain. Journal Of Manufacturing Technology Management, 16(2), pp. 127-144.

MEIXELL, M. J. and GARGEYA, V. B. (2005) Designing global supply chains: A review & critique of the model-based literature. Transportation Research Part E: Logistics and Transportation Review, 41(6), pp.531-550.

MELAO, N. and PIDD, M. (2006) Using component technology to develop a simulation library for business process modelling. European Journal of Operational Research, 172(1), pp. 163-178.

MENDES, E., MOSLEY, N., PASTOR, O., FONS, J., PELECHANO, V., (2006), Conceptual modelling of web applications: The OOWS approach, Springer: Berlin Heidelberg

MENTZER, J.T., DEWITT, W., KEEBLER, J.S., MIN, S., NIX, N.W., SMITH, C.D. and ZACHARIA, Z.G. (2001) Defining supply chain management. Journal of Business Logistics, 22(2), pp. 1-25.

MEREDITH, J. R., RATURI, A., AMOAKO-GYAMPAH, K. and KAPLAN, B. (1989) Alternative research paradigms in operations. Journal of Operations Management, 8(4), pp. 297-326.

MEREDITH, J. (1993) Theory building through conceptual methods, International Journal of Operations & Production Management, 13(5), pp. 3 – 11.

MEREDITH, J., (1998) Building operations management theory through case and field research, Journal of Operations and Production Management, 13(5), pp. 3 – 11.

MEYR, H., ROHDE, J., and STADTLER, H. (2002) Basics for modelling. IN: STADTLER, H. and KILGER, C. (eds.) Supply Chain Management and Advanced Planning, second ed. Springer:Berlin, pp. 45–70.

MILLER, S. and PEGDEN, D. (2000) Manufacturing simulation: Introduction to manufacturing simulation. IN: Proceedings of the 32nd conference on Winter Simulation 2000. Orlando, Florida. IEEE, pp.63-66.

MILGATE, M. (2001) Supply chain complexity and delivery performance: an international exploratory study. Supply Chain Management: An International Journal, 6(3), pp. 106 – 118.

MIN, H. and ZHOU, G. (2002) Supply chain modelling: past, present and future. Computers & Industrial Engineering, 43(1-2), pp. 231-249.

MINTZBERG, H., RAISINGHANI, D., THEORET, A., (1976) The structure of ‘unstructured’ decision processes, Administrative Science, Q. 21, pp. 246 – 275.

MONCZKA, R.M. and TRENT, R.J. (1991) Global sourcing: A development approach. International Journal of Purchasing and Materials Management, 27(2), pp. 2-8.

MORGAN, G. and SMIRCICH, L. (1980) The case for qualitative research. Academy of Management Review, 5, pp. 491 – 500.

MORRIS, W.T. (1967) On the art of modelling. Management science, 13(12), B707-717.

MOSER, C., & KALTON, G., (1971) Survey methods in social investigation, (Reprinted 1993 ed.): Gower.

MURCH, R. (2005) Methodologies in IT: Comprehension, selection, and implementation. [Online] http://www.informit.com/articles/article.aspx?p=370635 [Accessed 15/03/2006].

MUSSELMAN, K. J. (1994) Guidelines for simulation project success. IN: TEW, J. D., MANIVANNAN, S., SADOWSKI, D. A. and SEILA, A. F. (eds) Proceedings of the 1994 Winter Simulation Conference. 1994. SCSI, pp. 88-95.

NANCE, R.E. (1994) The conical methodology and the evolution of simulation model development. Annals of Operations Research, 53(1), pp. 1–45.

242

NANCE, R.E. and ARTHUR, J.D. (2006) Software requirements engineering: Exploring the role in simulation model development. IN: Third Operational Research Society Simulation Workshop (SW06)., pp.117–127.

NAIM, M.M., CHILDERHOUSE, P., DISNEY, S.M. and TOWILL, D.R. (2002) A supply chain diagnostic methodology: determining the vector of change. Computers & Industrial Engineering, 43(1-2), pp. 135-157.

NEW, S.J. (1997) The scope of supply chain management research. Supply Chain Management: An International Journal, 2(1), pp. 15-22.

NORDGREN, W.B. (1995) Taylor II manufacturing simulation software. IN: ALEXOPOULOS, C., KANG, K., LILEGDON, W.R. and GOLDSMAN, D. (eds). Proceedings of the 1995 Winter Simulation Conference. 1995. pp. 401–404.

NYDICK, R.L., LIBERATORE, M.J. and CHUNG, Q.B. (2002) Modeling by elaboration: An application to visual process simulation. INFOR, 40(4), pp. 347-361.

ONGGO, B.S.S., GUNAL, M.M., MADEN, W. (2008) The conceptual model of a distribution warehouse simulation, UK Operational Research Society Simulation Workshop 2008 (SW08), 1st - 2nd April 2008, Worcestershire, England.

ORMEROD, R.J. (2001) Viewpoint: the success and failure of methodologies – a comment on Connell (2001): evaluating soft OR. Journal of the Operational Research Society, 52(10), pp. 1176 – 1179.

OTTO, A. and KOTZAB, H. (2003) Does supply chain management really pay? Six perspectives to measure the performance of managing a supply chain. European Journal of Operational Research, 144(2), pp. 306–320.

OUYANG, Y. (2007) The effect of information sharing on supply chain stability and the bullwhip effect. European Journal of Operational Research, 182(3), pp. 1107-1121.

OWEN, C., LOVE, D., and ALBORES, P. (2008) Selection of simulation tools for improving supply chain performance. IN: Proceedings of the Operational Research Society Simulation Workshop (SW08), 1st – 2nd April, Worcestershire, UK.

PACE, D.K. (1999) Development and documentation of a simulation conceptual model. IN: Proceedings of the 1999 Fall Simulation Interoperability Workshop. (Accessed August 2005).

PACE, D.K. (2000a) Ideas about simulation conceptual model development. Johns Hopkins APL Tech Dig, 21, pp. 327–336.

PACE, D.K. (2000b) Simulation conceptual model development. IN: Proceedings of the 2000 Spring Simulation Interoperability Workshop, www.sisotds.org, (Accessed June 2005).

PAIK, S-K. and BAGCHI, P.K. (2007) Understanding the causes of the bullwhip effect in a supply chain. International Journal of Retail & Distribution Management, 35(4), pp. 308 – 324.

PEGDEN, C.D., SHANNON, R.E. and SADOWSKI, R.P. (1995) Introduction to simulation using SIMAN, 2nd Ed. New York: McGraw-Hill.

PERSSON, F. and ARALDI, M. (2009) The development of a dynamic supply chain analysis tool – Integration of SCOR and discrete event simulation. International Journal of Production Economics, 121, pp. 574 – 583.

PERSSON, F. and OLHANGER, J. (2002) Performance simulation of supply chain designs. International Journal of Production Economics, 77(3), pp. 231-245.

PETROVIC, D. (2001) Simulation of supply chain behaviour and performance in an uncertain environment. International Journal of Production Economics, 71(1-3), pp. 429-43.

243

PETROVIC, D., ROY, R. and PETROVIC, R. (1998) Modelling and simulation of a supply chain in an uncertain environment. European Journal of Operational Research. 109(2), pp. 299-309.

PHELPS, R.A., PARSONS, D.J. and SIPRELLE, A.J. (2001) SDI supply chain builder :Simulation from atoms to the enterprise. IN: PETERS, B.A., SMITH, J.S., MEDEIROS, D.J., and ROHRER, M.W. (eds.), Proceedings of the 2001 Winter Simulation Conference. Arlington, Virginia, 2001. IEEE, pp. 246–249.

PIDD, M. (1996) Five simple principle of modelling. IN: CHARNES, J.M., MORRICE, D.J., BRUNNER, D.T., SWAIN, J.J. (eds) Proceedings of the 28th conference on Winter simulation. Coronado, CA. 8-11 December 1996. IEEE, pp.721-728.

PIDD, M. (1998) Computer simulation in management science, 4th ed. Chichester: Wiley.

PIDD, M. (1999) Just modelling through: a rough guide to modelling. Interfaces, 29(2), pp. 118-132

PIDD, M. (2003) Tools for thinking. Modelling in management science, 2nd ed. Chichester: Wiley.

PIDD, M. (2004a) Computer simulation in management science, 5th

ed. Chichester: Wiley.

PIDD, M. (2004b) Simulation worldviews: so what? IN: INGALLS, R.G.,ROSSETTI, M.D., SMITH., J.S., and PETERS., B.A. (eds) Proceedings of the 2004 Winter Simulation Conference. Washington, D.C., 5–8 December 2004. WSC, pp. 288-292.

PLANE, D.R. (1997) How to build spreadsheet models for production and operations management. OR/MS Today, 24(2), pp. 50 – 54.

PLATTS, K.W. (1990) Manufacturing audit in the process strategy formulation. (PhD), University of Cambridge.

PLATTS, K.W. (1993) A process approach to researching manufacturing strategy. International Journal of Operations & Production Management, 13(8), pp. 4-17

PLATTS, K.W. (1994) Characteristics of methodologies for manufacturing strategy formulation, Computer Integrated Manufacturing Systems, 7(2), pp. 93-99.

PLATTS, K.W. and CANEZ, D.R. (2002) Make vs. buy decisions: A process incorporating multi-attribute decision-making. International Journal of Production Economics, 77, pp. 247 – 257.

PLATTS, K.W. and GREGORY, M. J. (1990) Manufacturing audit in the process of strategy formulation. International Journal of Operations & Production Management, 10(9), pp. 5-26

PLATTS, K.W., MILLS, J.F., BOURNE, M.C., NEELY, A.D., RICHARDS, A.H. and GREGORY, M.J. (1998) Testing manufacturing strategy formulation processes. International Journal of Production Economics, 56-57, pp. 517-523.

PLATTS, K.W., MILLS, J.F., NEELY, A.D., GREGORY, M.J. and RICHARDS, A.H. (1996b) Evaluating the manufacturing strategy formulation processes. International Journal of Production Economics, 46-47, pp. 233-240.

PLATTS, K.W. and TAN, K.H. (1996a) Operationalising strategy: Mapping manufacturing variables. International Journal of Production Economics, 89(3), pp. 379-393.

PLATTS, K.W., MILLS, J.F., RICHARDS, A.H., BOURNE, M.C.S. and NEELY, A.D. (2001) Researching strategic management processes. IN: Twelfth Annual Conference of the Production and Operations Management Society. POM 2001, 30 March - 2 April, Orlando, Florida.

POLUHA, R.G. (2007) Application of the SCOR model in supply chain management. New York, USA: Cambria Press.

POWELL, S.G. (1995a) Teaching the art of modelling to MBA students. Interfaces 25(4), pp.88–94.

POWELL, S.G. (1995b) Six key modelling heuristics. Interfaces 25(4), pp.114–125.

244

POWELL, S. G. (1997) Leading the spreadsheet revolution. OR/MS Today, 24, pp. 8 – 10.

POWELL, S.G. and WILLEMAIN, T.R. (2007) How novices formulate models. Part I: Qualitative insights and implications for teaching. Journal Operations Research Society, 58(8), pp, 983–995.

PRITSKER, A.A.B. (1995) Introduction to simulation and SLAM II, 4th ed. New York: Wiley.

PRITSKER, A.A.B. (1998) Principles of simulation modeling. IN: BANKS, J. (ed) Handbook of Simulation: Principles, Methodology, Advances, Applications, and Practice. New York: Wiley, 31-51

PRITSKER, A.A.B., SIGAL, C.E. and HAMMESFAHR, R.D. (1989) Slam II: Network models for decision support. Englewood: PRENTICE-HALL.

REINER, G. (2005) Customer-oriented improvement and evaluation of supply chain processes supported by simulation models. International Journal of Production Economics, 96(3), pp. 381–395.

REINER, G., and TRCKA, M. (2004) Customized supply chain design: problems and alternatives for a production company in the food industry. A simulation based analysis. International Journal of Production Economics, 89(2), pp. 217-29.

RIDALL, C. E., BENNET, S. and TIPI, N. S. (2000) Modeling the dynamics of supply chains. International Journal of Systems Science, 31(8), pp. 969–976.

RIIS, J.O., SMEDS, R. and VAN LANDEGHEM, R. (eds.) (2000) Games in operations management, Boston, MA: Kluwer.

ROBINSON, S. (1994) Simulation projects - Building the right conceptual model. Industrial Engineering, 26(9), pp. 34 - 36.

ROBINSON, S. (1997) Simulation model verification and validation: Increasing the users confidence. IN: Proceedings of the 1997 Winter Simulation Conference, Atlanta, Georgia 1997, ACM, pp.53-59.

ROBINSON, S. (2004a) Designing the conceptual model in simulation studies. IN: BRAILSFORD, S.C., OAKSHOTT, L., ROBINSON, S., and TAYLOR, S.J.E. (eds) Proceedings of the 2004 Operational Research Society Simulation Workshop (SW04). Birmingham, UK, 2004. Operational Research Society, pp.259-266.

ROBINSON, S. (2004b) Simulation: The practice of model development and use. Chichester: Wiley.

ROBINSON, S. (2005) Discrete-event simulation: from the pioneers to the present, what next? Journal of the Operational Research Society, 56, pp. 619–629.

ROBINSON, S. (2006a) Conceptual modeling for simulation: Issues and research requirements. IN: PERRONE, L. F., WIELAND, F. P., LIU, J., LAWSON, B. G., NICOL, D. M. and FUJIMOTO, R. M. (eds) Proceeding of the 2006 Winter Simulation Conference. Monterey,CA, 3-6 December 2006. WSC, pp. 792-800.

ROBINSON, S. (2006b) Issues in conceptual modelling for simulation: Setting a research agenda. IN: GARNETT, J., BRAILSFORD, S., ROBINSON, S. and TAYLOR, S. (eds) Proceedings of the Operational Research Society Simulation Workshop 2006 (SW06). Birmingham, UK, 2006. Operational Research Society, pp.165-174.

ROBINSON, S. (2008a) Conceptual modelling for simulation part I: Definition and requirements. Journal of the Operational Research Society, 59 (3), pp. 278-290.

ROBINSON, S. (2008b) Conceptual modelling for simulation part II: A framework for conceptual modelling. Journal of the Operational Research Society, 59 (3), pp. 291-304.

ROBINSON, S. (2009) Conceptual modeling for simulation. Encyclopedia of Operations Research and Management Science (J.J. Chochran, ed.), New York: Wiley.

245

ROBINSON, S. and BHATIA, V. (1995) Secrets of successful simulation projects. IN: ALEXOPOULOS, C., KANG, K., LILEGDON, W.R. and GOLDSMAN, D. (eds) Proceedings of the 1995 Winter Simulation Conference. Arlington, VA, December 1995. IEEE: pp. 61-67.

ROSSI, P.H., WRIGHT, J.D. and ANDERSON, A.B. (1983), Handbook of survey research, Academic Press, New York, NY.

RYAN, J. and HEAVEY, C. (2006) Process modelling for simulation. Computers in Industry, 57(5), pp. 437 – 450.

SACHAN, A. and DATTA, S. (2005) Review of supply chain management and logistics research. International Journal of Physical Distribution & Logistics Management, 35(9), pp. 664 – 705.

SADOWSKI, R.P. (1989) The simulation process: Avoiding the problems and pitfalls, IN MacNAIR, K, J., MUSSELMAN, P., and HEIDELBERGER, P. (eds) Proceedings of the 21st Conference on Winter Simulation. Washington, D.C., 1989. ACM, pp. 72 - 79.

SALT, J. (1993) Simulation should be easy and fun. IN: EVANS, G.W., MOLLAGHASEMI, M., RUSSELL, E.C., BILES, W.E. (eds) Proceedings of the 1993 Winter Simulation Conference. Los Angeles, CA, 1993. ACM, pp. 1-5.

SARGENT, R. G. (1985) An expository on verification and validation of simulation models. IN: GANTZ, D. T., BLAIS, G. C. and SOLOMON, S. L. (eds) Proceedings of the 1985 Winter Simulation Conference. San Francisco, CA, 1985. ACM, pp.15-22.

SARGENT, R.G. (2004) Validation and verification of simulation models. IN: INGALLS, R.G., ROSSETTI, M.D., SMITH, J.S. and PETERS, B.A. (Eds) Proceedings of the 2004 Winter Simulation Conference. IEEE, pp. 17-28, 2004.

SARGENT, R.G. (2005) Verification and validation of simulation models. IN: Proceedings of the 37th conference on Winter simulation. Orlando, Florida, 2005. WSC, pp.130-143.

SARGENT, R.G. (2008) Verification and validation of simulation models. IN: MASON, S., HILL, R., MONCH, L. and ROSE, O. (eds) Proceedings of the 40th conference on Winter simulation. Miami, Florida, 7-10 December 2008. WSC, pp.157-169.

SARI, K. (2008) On the benefits of CPFR and VMI: A comparative simulation study. International Journal of Production Economics, 113(2), pp. 575-586.

SAUNDERS, M.J. (1995). Chains, pipelines, networks and value stream: the role, nature and value of such metaphors in forming perceptions of the task of purchasing and supply management. IN: First Worldwide Research Symposium on Purchasing and Supply Chain Management. Tempe, Arizona, pp. 476-485.

SAUNDERS, M.J. (1998) The comparative analysis of supply chains and implications for the development of strategies. IN: Seventh International IPSERA Conference. London, pp. 469-477.

SAUNDERS, M.N.K., LEWIS, P. and THORNHILL, A. (2003) Research Methods for Business Students, 3rd Ed. Harlow: Pearson

SCHEWE, K-D., and THALHEIM, B., (2005), Conceptual modelling of web information systems,

Data & Knowledge Engineering, 54(2), pp. 147 – 188.

SCHIERITZ, N. and MILLING, P. (2003) Modelling the forest on modelling trees: A comparison of system dynamics and agent based simulation. IN: EBERLEIN, R.L. et al (eds) Proceedings of the 21st International Conference of the System Dynamic Society. New York, 2003.

SCHMEISER, B. W. (2001) Some myths and common errors in simulation experiments, IN: PETERS, B. A., SMITH, J.S., MEDEIROS, D.J. and ROHRER, M.W. (eds) Proceedings of the 2001 Winter Simulation Conference. Arlington, VA, 12 September 2001. IEEE, pp. 39 – 46.

246

SCHÖNSLEBEN, P. (2004) Integral Logistics Management Planning & Control of Comprehensive Supply Chains, 2nd Ed. CRC Press.

SEURING, S.A. (2008) Assessing the rigor of case study research in supply chain management. Supply Chain Management: A International Journal, 13(2), pp. 128-137.

SEVINC, S. (1990) Automation of simplification in discrete event modelling and simulation. International journal of general systems, 18(2), pp. 125-142.

SHANE, D.G., (2005) Recombinant urbanism: Conceptual modeling in architecture, urban design, and city theory. John Wiley & Sons, Hoboken

SHANNON, R.E. (1975) Systems simulation: The art and science. Eaglewood, Prentice-Hall.

SHANNON, R.E. (1992) Introduction to simulation, IN: Proceedings of the 1992 Winter Simulation Conference. Arlington, Virginia, 13-16 December 1992. ACM, pp. 65-73.

SHEPHERD, C. and GUNTER, H. (2006) Measuring supply chain performance: Current research and future directions. International Journal of Productivity and Performance Management, 55(3/4), pp. 242-258.

SIMCHI-LEVI, D., KAMINSKY, P. and SIMCHI-LEVI, E. (2003) Designing and managing the supply chain: Concepts, strategies and case studies, 2nd ed. Boston, MA: Irwin/McGraw-Hill.

SMITH, G.A. (2003) Using integrated spreadsheet modelling for supply chain analysis. Supply Chain Management: An International Journal, 8(4), pp. 285-290.

SODHI, M.S. (2001) Applications and opportunities for operations research in internet-enabled supply chains and electronic marketplaces. Interfaces, 31(2), pp. 56–69.

SOUNDERPANDIAN, J.D.B.A. (1989) MRP on spreadsheets: a do-it-yourself alternative for small firms. Production and Inventory Management Journal, Second Quarter. 30(2), pp.6–11.

SOUTHHARD, P.B. and SWENSETH, S.R. (2008) Evaluating vendor-managed inventory (VMI) in non-traditional environments using simulation. International Journal of Production Economics, 116(2), pp. 275-287.

SPARLING, D. (2002) Teaching tools – the Beer game; Simulations and supply chains: strategies for teaching supply chain management. Supply Chain Management: An International Journal, 7(5), pp. 334 – 342.

SPEKMAN, R. (1981) A strategic approach to procurement planning. Journal of Purchasing and Materials Management pp. 3–9.

SPEKMAN, R.E., SPEAR, J. and KAMAUFF, J. (2002) Supply chain competency: learning as a key component. Supply Chain Management: A International Journal, 7(1), pp. 41-55.

SPENGLER, T. and SCHROTER, M. (2003) Strategic management of spare parts in closed-loop supply chains: A system dynamics approach. Interfaces, 33(6) pp.7-17.

SRIVASTAVA, R.K., SHERVANI, T.A. and FAHEY, L. (1999) Marketing, business processes, and shareholder value: An organizationally embedded view of marketing activities and the discipline of marketing. The Journal of Marketing, 63, pp. 168-179.

STECKEL, J. H., GUPTA, S. and BANERJI, A. (2004) Supply chain decision making: Will shorter cycle times and shared point-of-sale information necessary help? Management Science, 50(4), pp. 458 – 464.

STEPHENS, S. (2001) Supply Chain Operations Reference Model Version 5.0: A new tool to improve supply chain efficiency and achieve best practice. Information Systems Frontiers, 3(4), pp. 471-476.

247

STERMAN, J.D. (1989) Modelling managerial behaviour: Misperceptions of feedback in a dynamic decision making experiment. Management Science, 35(3), pp. 321 – 339.

STERMAN, J.D. (1992) Teaching takes off: flight simulators for management education, OR/MS Today, October, pp. 40 – 44.

STERMAN, J.D. (2000) Business dynamics: Systems thinking and modeling for a complex world, Boston, MA: McGraw-Hill

STEWART, G. (1997) Supply-chain operations reference model (SCOR): the first cross-industry framework for integrated supply-chain management. Logistics Information Management, 10(2), pp. 62-67.

STONE, J. and LOVE, D. (2007) Modelling the relationship between local logistics management decisions and overall supply chain performance: a research agenda. International Journal of Business Performance Management, 9(2), pp. 240 – 252.

STUART, I., McCUTCHEON, D., HANDFIELD, R., McLACHLIN, D., SAMOSON, D., (2002) Effective case research in operations management: a process perspective, Journal of Operations Management, 20, pp. 419 – 433.

SWAFFORD, P., GHOSH, S. and MURTHY, N. (2006) The antecedents of supply chain agility of a firm: Scale development and model testing. Journal of Operations Management, 24(2), pp. 170-188.

SWAMINATHAN, J.M., SMITH, S.F. and SADEH, N.M. (1998) Modelling supply chain dynamics: A multi-agent approach. Decision Sciences. Blackwell Publishing Limited.

SUDDABY, R., (2006) What grounded theory is not, Academy of Management Journal, 49, pp. 633 – 642.

SUPPLY-CHAIN COUNCIL. (2008) Supply-Chain Operations Reference-model, Overview of SCOR Version 9.0 [online]. Available from http://www.supply-chain.org, [Accessed 12/01/08].

SYMEONIDIS, A.L., NIKOLAIDOU, V. and MITKAS, P.A. (2008) Sketching a methodology for efficient Supply Chain Management agents enhanced through Data Mining. International Journal of Intelligent Information and Database Systems, 2(1), pp.49-69

TAHA, H.A. (1992) Simulation with SIMNET II. Simtec, Inc., Fayetteville, Arkansas.

TAN, K.C. (2001) A framework of supply chain management literature. European Journal of Purchasing & Supply Management, 7(1), pp.39-48.

TAN, K.H. and PLATTS, K.W. (2002) Managing Manufacturing Action Plans. International Journal of Innovation Management, 6(4), pp. 369-385.

TAN, K.C., KANNAN, V.R. and HANDFIELD, R.B. (1998) Supply chain management: supplier performance and firm performance. International Journal of Purchasing and Material Management, 34(3), pp.2-9.

TAN, K.C., KANNAN, V.R. and HARDFIELD, R.B. (1999) Supply chain management: an empirical study of its impact on performance. International Journal of Operations & Productions Management. 19(10), pp. 1034-1052.

TANG, NELSON K. H., BENTON H., LOVE D., ALBORES P., BALL P D., MACBRYDE J C., BOUGHTON N. and DRAKE P. (2004). Developing an Enterprise Simulator to Support Electronic Supply Chain for B2B Electronic Business. Production Planning and Control, 15(6), pp. 572-83

TANIR, O and SEVINC, S. (1994) Defining requirements for a standard simulation environment. Computer, 27(2), pp. 28-34.

248

TAYLOR, G.D., LOVE, D.M., WEAVER, M.W. and STONE, J. (2008) Determining inventory service support levels in multi-national companies. International Journal Production Economics, 116(1) pp. 1-11.

TAYLOR , S, J, E. and ROBINSON, S. (2006) So where to next? A survey of the future for discrete-event simulation. Journal of Simulation, 1(1), pp. 1 – 6.

TAYLOR, S.J.E., ROBINSON, S. and LADBROOK, J. (2003) Towards collaborative simulation modelling: improving human-tohuman interaction through groupware. IN: AL-DABASS, D. (ed) Proceedings of the 17th European Simulation Multiconference (ESM 2003), Society for Computer Simulation, Delft, pp 474–482.

TERZI, S. and CAVALIERI, S. (2004) Simulation in the supply chain context: a survey. Computers in industry, 53(1) pp. 3-16.

THOMAS, A. and CHARPENTI, P. (2005) Reducing simulation models for scheduling manufacturing facilities. European Journal of Operational Research, 161(1), pp. 111-125.

TOWILL, D.R. (1991) Supply chain dynamics. International Journal of Computer IntegratedManufacturing, 4(4), pp. 197-208.

TOWILL, D.R. (1996a) Industrial dynamics modelling of supply chains. Logistics Information Managment 9(4), pp. 43-56.

TOWILL, D.R. (1996b) Time compression and supply chain management - a guided tour. Supply Chain Management 1(1), pp. 15-27.

TOWILL, D.R., NAIM, M.M. and WIKNER, J. (1992) Industrial dynamics simulation models in the design of supply chains. International Journal of Physical Distribution & Logistics Management, 22(5), pp. 3-13.

TROUNG, T. and AZADIVAR, F. (2005) Optimal design methodologies for configuration of supply chains. International Journal of Production Research, 43(11),pp. 2217–2236.

TUMAY, K (1995). Business process simulation. IN: Alexopoulos, C., KANG, K., LILEGDON, W.R., GOLDSMAN, D. (eds). Proceedings of the Winter Simulation Conference 1995. Arlington. VA: IEEE

TURK, Z., (2001), Phenomenological foundations of conceptual product modeling in architecture, engineering and construction, Artificial Intelligence in Engineering, 15(2), pp. 83 – 92.

TYNDALL, G., GOPAL, C., PATSCH, W. and KAMAUFF, J. (1998) Supercharging supply chains: New ways to increase value through global operational excellence. New York: John Wiley & Sons.

ULGEN, O., GUNAL, A. and SHORE, J. (1996) Pitfalls of simulation modeling and how to avoid them by using a robust simulation methodology. IN: Proceedings of the Autosimulations Symposium, Autosimulations, Bountiful, UT, 1996, pp. 21-31.

ULRICH, K.T. and PEARSON, S. (1998) Assessing the importance of design through product archaeology. Management Science, 44, pp. 352-369.

VALUE CHAIN GROUP (2008) Introduction to VCOR, [online]. Available from http://www.value-chain.org. [Accessed 12/01/08].

VAN DER POL, J.M. and AKKERMANS, H.A. (2000) No one in the driver’s seat: an agent-based modelling approach to decentralised behaviour in supply-chain co-ordination. Eleventh International Working Seminar on Production Economics. Pre-prints, (Igls, Austria), 3, p.621–642.

VAN DER VORST, J. and BEULENS, A. J. M. (2002) Identifying sources of uncertainty to generate supply chain redesign strategies. International Journal of Physical Distribution & Logistics Management, 32(6), pp. 409-430.

249

VAN DER ZEE, D. J. and VAN DER VORST, J. G. A. J. (2005). A modelling framework for supply chain simulation: Opportunities for improved decision making. Decision Sciences, 36(1), pp. 65-95.

VAN DER ZEE, D.J. and VAN DER VORST, J. (2007) Guiding principles for conceptual model creation in manufacturing simulation. IN: HENDERSON, S.G., BILLER, B., HSIEH, M.-H., SHORTLE, J., TEW, J.D. and BARTON, R.R. (eds.) Proceedings of the 2007 Winter Simulation Conference. Washington, D.C. 2007. IEEE: pp. 776-784.

VAN DER ZEE, D-J., POOL, A. and WIJNGAARD, J. (2008) Conceptual modelling for participative simulation – a case study on lean planning. IN: UK Operational Research Society Simulation Workshop 2008 (SW08), 1st - 2nd April 2008, Worcestershire, England, UK.

VAN LANDEGHEM, R. and PERSOONS, K. (2001) Benchmarking of logistical operations based on a causal model. International Journal of Operations & Productions, 21(1/2), pg.254.

VLAJIC, J. V., VAN DER VORST, J. G. A. J. and HENDRIX, E. M. T. (2008) Food supply chain network robustness - A literature review and research agenda, Working paper No. 42, Mansholt Graduate School of Social Sciences, Wageningen University.

VOSS, C., TSIKRIKTSIS, N. and FROHLICH, M. (2002). Case research in operations management. International Journal of Operations & Production Management, 22(2), pp. 195-219.

WACKER, J. G., (1998) A definition of theory: research guidelines for different theory-building research methods in operations management, Journal of Operations Management, 16(4), pp. 361 – 385.

WAND, Y., MONARCHI, D, E., PARSONS, J., WOO, C, C., (1995) Theoretical foundations for conceptual modelling in information systems development, Decision Support Systems, 15, pp. 285 – 304.

WANG G., HUANG S.H. and DISMUKES J.P. (2004) Product-driven supply chain selection using integrated multi-criteria decision making methodology. International Journal of Production Economics, 91, pp. 1-15.

WANG, W. and BROOKS, R.J. (2007a) Improving the understanding of conceptual modelling. Journal of Simulation, 1(3), pp 153 – 158.

WANG, W. and BROOKS, R.J. (2007b) Empirical Investigations of conceptual modelling and the modelling process. IN: Proceedings of the 2007 Winter Simulation Conference. Washington, D.C., 9-12 December 2007. IEEE, pp.762-770.

WANG, W. and BROOKS, R.J. (2008) Conceptual modelling and the modelling process in simulation projects: A survey of simulation modellers. IN: UK Operational Research Society Simulation Workshop 2008 (SW08), 1st - 2nd April 2008, Worcestershire, England, UK.

WARD, S.C. (1989) Arguments for constructively simple models. Journal of the Operational Research Society, 40(2) pp. 141-153.

WEAVER, M., LOVE, D. and ALBORES, P. (2006) Towards the development of a supply strategy evaluation methodology. "Moving Up the Value Chain", Conference of the European Association of Operations Management. Strathclyde University, Scotland, UK.

WEAVER, M., LOVE, D. and ALBORES, P. (2007) A decision aid to select techniques to evaluate supply chain improvement options, "Managing Operations in an Expanding Europe", 14th Annual Conference of the European Association of Operations Management. Bilkent University, Ankara, Turkey.

WEAVER, M., LOVE, D. and ALBORES, P. (2008) Supply chain improvement options and their decision variables. "Tradition and Innovation in Operations Management",. IN: 15th Annual EurOMA Conference of the European Association of Operations Management. University of Gronigen, Netherlands

250

WEBSTER, M. (2002) Supply system structure, management and performance: a conceptual model. International Journal of Management Reviews, 4(4),pp. 353-369.

WEICK, K.E., 1989. Theory construction as disciplined imagination. Academy of Management Review, 14(4), pp. 515–531.

WIKNER, J., TOWILL, D. and NAIM, M. M. (1991) Smoothing supply chain dynamics. International Journal of Production Economics, 22(3), pp. 231 – 248.

WILLEMAIN, T.R. (1994) Insights on modelling from a dozen experts. Operations Research, 42(2), pp. 213 – 222.

WILLEMAIN, T.R. (1995) Model formulation: What experts think about and when, Operations Research, 43(6), pp. 916-932

WILLEMAIN, T.R. and POWELL, S.G. (2007) How novices formulate models. Part II: A quantitative description of behaviour. Journal Operations Research Society, 58(10), pp. 1271–1283.

WONG, C.Y. and JOHANSEN, J. (2008) Empirical testing of forecast update procedure for seasonal products, International Journal of Information Technology and Management, 7(1) pp. 60-75.

WONG, W.P. and WONG, K.Y. (2008) A review on benchmarking of supply chain performance measures. Benchmarking: An International Journal, 15(1), pp. 25-51.

WU, T. and O’GRADY, P. (2004). A methodology for improving the design of a supply chain. International Journal of Computer Integrated Manufacturing, 17(4), pp. 281-293.

YEE, C.L. and PLATTS, K.W. (2006) A framework and tool for supply network strategy operationalisation, International Journal of Production Economics, 104, pp. 230 – 248.

YEE, C.L. and TAN, K.H. (2004) A process and tool for supply network analysis, Industrial Management & Data Systems, 104(4), pp. 355-363.

YIN, H.Y. and ZHOU, Z.N. (1989) Simplification techniques of simulation models. IN: Proceedings of Beijing International Conference on System Simulation and Scientific Computing. 1989. IEEE: pp 782–786.

YIN, R.K. (1981) The case study crisis: Some answers. Administrative Science Quarterly, 26(1), pp. 58-65.

YIN, R.K (1994) Case study research: Design and methods (2nd ed.). Beverly Hills, CA: Sage Publishing

YIN, R.K. (2003) Case study research: Design and methods. London: Sage Publications

ZEIGLER, B.P. (1976) Theory of modelling and simulation. New York: Wiley.

ZENG, A. (2003) Global sourcing: process and design for efficient management. Supply Chain Management: An International Journal, 8(4), pp.367-379.

ZENG, A. and ROSSETTI, C. (2003) Developing a framework for evaluating the logistics costs in the global sourcing process. International Journal of Physical Distribution & Logistics Management, 33(9), pp. 785-803.

ZINNES, D.A. (1966) A comparison of hostile behaviour of decision-makers in simulated and historical data. World Politics, 18(3), pp. 474 – 502.

251

Appendix A Principles/observations made in the design of the SCM2

Table A.1 Principle/observations when designing phase one Principle/observation noted by

Robinson (2004, pg. 78 – 81) Remarks from application Influence on the design

Necessary for the modeller to develop a good understanding of the problem situation if he/she is to develop a model that adequately describes the real world

The description needs to be structured in a way to drive the following phases. Importantly, SCOR terminology could aid in a description of the improvement, objective and supply setting.

Describe adequately the improvements, objective and supply setting (in step 1.1)

Accuracy of the description provided by the clients may be dubious

An incorrect description will lead to poor analysis in forthcoming phases. It needs to be checked for ‘correctness’ before leaving the phase.

Check the descriptions for ‘correctness’ (in step 1.5)

Clients may lack a good understanding of the cause and effect relationships within problem

How an improvement that has been selected will have an impact upon supply chain performance attributes. If no perceived impact can be identified then the improvement may be inappropriate; thus can be eliminated without the need for simulation

Check that the means by which each improvement is to achieve each objective, by bringing about the desired change in the supply system (in step 1.4)

Client may have a different perspective on the problem

Agreement needs to be reached between the participants involved in the study otherwise the analysis will be flawed from the offset. Using SCOR enabled common and standard language to be applied.

Obtain information from the client on the real world problem and describe this using SCOR terms (e.g. impact on supply chain performance attributes) (in step 1.2)

Role of the modeller is to learn from the clients about the problem

The modeller needs to draft a description of supply problem and check that it is correct with the client

Provide a text description of the supply problem (in step 1.4)

Description of the problem, in particular the objectives can be used as a means for validating the conceptual model

The information provided in subsequent phases to describe the conceptual model can be validated against the supply problem (purpose at hand)

Incorporated into later phases and a final validation at the end of the process (see phase 7)

Clients who have a poor grasp of the problem will benefit from more formal problem structuring methods to be used

The client may find it useful prior to entering the first phase of the methodology to use a formal problem structuring method

Include as an approach that could be used prior to conceptual modelling (point of entry)

The objectives should be expressed in terms of the level of performance required (also Beamon, 1998)

Expressed in terms of desired impact upon supply chain performance attributes (e.g. increase, decrease, maintain)

Include in the description of the objectives of study (in step 1.2)

The client may find it difficult to express the set of objectives

Useful to force the modeller to consider how each improvement is to achieve the desired objective. SCOR can provide information to support this

The means by which the improvement is to achieve the desired objective is included as a step (in step 1.4)

Understanding can change during a simulation project, so can the objectives. This will impact on the design of the model

Ensure that the participants agree amongst themselves that the supply problem is described correctly, and return at the end of the process.

The phase is not exited until the checks have been satisfied and it is re-entered if the final validation check identified any issues to be resolved (in step 1.5 and in considered in phase 7)

252

Table A.2 Principle/observations made that included the design of phase two Principle/observation Remarks from application Influence on the design

The metrics cannot be described if the objective has not been clearly defined in the supply problem

The metrics are derived from the impact upon performance attributes described in phase 1

Phase cannot be entered unless the supply problem has been checked for correctness (point of entry)

The responses refer to the outputs from the model that should be achieved (Robinson, 2004, pg. 82)

The performance attributes can be decomposed into specific performance metrics; SCOR provides a host of metrics for each performance attribute

Decompose the impact on supply performance attributes into specific performance metrics (in step 2.1)

The objectives may change as the project progresses (Robinson, 2004, pg. 83) e.g. as a result of a change to the objectives of study

The performance metrics were well defined and agreed before proceeding. For the BeerCo case, an alternative delivery performance metric was considered which had an impact upon the analysis. The check should be redone in a final validation procedure.

Check that the performance metrics are ‘correct’ (in step 2.4); Return to the phase if the final validation identifies any issues regarding the objectives (in step 7.2)

Performance metrics could be decomposed from the performance attributes when using SCOR

The hierarchy of metrics could be consulted to determine the metric that best describes the objective of study

SCOR is used to identify and describe supply chain performance metrics at three levels of detail (in step 2.1)

Descriptions of a performance metric can be extracted from SCOR: calculation and the process elements that provide data to perform each calculation

For each performance metric SCOR provided standard details for all performance metrics

Define the calculation and data sources for each metric (in step 2.2)

The actor needs to be defined for each data source

The actors that provide data sources determine the measurement span. The model boundary cannot be formulated without the actors being specified.

Define the nature of the measurement for each metric (in step 2.2)

How each objective to be measured needs to be checked

The checks could be met for both cases. The information provided could be used to drive the boundary formulation.

Include a check and state that the phase cannot be exited until the check has been satisfied (in step 2.4)

The processes that provide a data source for each metric are critical components that need to be included

The interconnections to be identified need to provide sufficient links between the improvement that will have an impact on a objective and the supply setting

Treat these processes as ‘core’ – to initiate the model formulation process (purpose of phase 2)

253

Table A.3 Principle/observations made that influenced the design of phase three Principle/observation Remarks from application Influence on the design

The phase can be entered at the same time as the description of the objective but it cannot be initiated until the supply problem has been checked.

Difficult to describe the improvement if it has not been described previously.

State that the phase can be completed at the same time as phase 2, but not until the supply problem has been checked (point of entry).

In a SCM improvement project the means by which it is proposed that the objectives can be achieved refers to the improvement to be evaluated (the business practice)

An improvement can be selected from the SCOR practice or can be used as a guide to describe a specific improvement

The boundary of the model is formulated initially from the core process elements (purpose of phase 3).

How each improvement is to represented can be described using standard SCOR terminology

As above, SCOR describes each practice and provides information on the processes germane to implementing them

Structure the representation of the improvement using SCOR terminology and descriptions (in step 3.1)

SCOR provides over 420 practices with description of the processes that are germane to each practice at different levels of process decomposition; describes inputs that interconnect between processes

Improvements could be selected from SCOR and adapted to the situation (e.g. actors who implement practice)

The list of practices can be used as a guide for describing a supply improvements, in particular their processes (in step 3.1 and 3.2)

SCOR describes the ‘causes’ of an improvement but not necessarily suggest the ‘effect’ relationship

SCOR practices could be used to describe the practices but care must be taken to ensure the ‘effect’ of the improvement on other business processes in the supply system are noted

The effect of an improvement must also be described (in step 3.1), specified by actor (in step 3.2)

Actor associated with implementing each business process needs to be defined

SCOR does not indicate the actors that would implement a practice, it is situational to the supply problem

Actors are associated with each business process (in step 3.2)

How each process elements is to be represented needs to be checked for correctness

An incorrect representation of the improvement will lead to the wrong processes being described which initiate the analysis of the model boundary

Check is implemented at the end of the phase; if it is not completed satisfactory the phase is repeated (in step 3.3)

The processes germane to a particular improvement are critical components that need to be included in the model

Treat these processes as ‘core’ – to initiate the model formulation process

The interconnections to be identified need to provide sufficient links between the improvement that will have an impact on a objective and the supply setting (used in phase 4)

254

Table A.4 Principle/observations made that influenced the design of phase four Principle/observation Remarks from application Influence on the design

The core process elements need to be described and checked for ‘correctness’ prior to identifying candidate process elements.

The core process elements are determined from the improvement and objective and the model boundary is formulated from the core process elements. Therefore, it is essential that these are correct.

Check implemented in previous phase before proceeding (point of entry)

The phase is initiated by listing the core process elements, followed by re-entering the phase when promoted process elements are identified in phase 5.

The phase starts with a list of core process elements (‘start simple and add’). The phase can be re-entered when processes are promoted in phase 5; this must be described in detail and noted that it is done in rounds for the purpose of consistency.

Iteration between steps in phase four and five (Point of entry and exit)

The included process elements can be listed with their associated inputs and the process element that provides the source.

The core process elements can be listed with their inputs and the source process element that generates the input. The boundary is formulated by considering the interconnections between the core process elements and those in the immediate supply setting for inclusion.

List the process elements with their inputs and source process elements that generate the input (in step 4.1)

SCOR describes the interconnections between processes for various manufacturing environments (i.e. MTO, MTS, ETO)

SCOR v.9 presents all the possible interconnections to each manufacturing environment while older versions specified which interconnections are appropriate

Creation of a template with the data necessary to be extracted. Data is checked with earlier versions of SCOR (in step 4.1)

SCOR loosely indicates the source actors for each process element. Actors must be included for each interconnection.

SCOR does not describe how processes interact outside of an organisation, between suppliers and customers. It does however provide the critical connections such as ‘order signal’ and lists ‘supplier’ or ‘customer’

Be clear in the guide that an actor must be specified for each process. Add detail to the template noted above (in step 4.1).

Considerable number of typo’s that questioned the reliability of SCOR v.9

Due to a major overhaul of the description of interconnections, many errors could be identified that have not been documented. Upon inspection of SCOR v.8, these typos did not exist and more detail was provided on how the process elements connect within an organisation and with external organisations.

Cross reference SCOR v.9 with v.8 and correct any errors in the template (in step 4.1)

Treating each entry separately but common inputs, source process elements for each actor could be consolidated

In practice, this would be difficult due to the number of entries considered. The boundary status had to distinguish between ‘Yes’ or ‘No’. This allowed candidates that may have been simplified or excluded previously be considered based upon how the interconnections have been traced. An opportunity to provide a solution to this problem is considered.

Common inputs from source process elements could be consolidated so that they are only considered once (step 4.1)

No interaction is required with the client to identify the relationships between components; efforts can be focused on formulating the model boundary in phase 5.

The phase is the most time consuming in the conceptual modelling process as it involves listing many interconnections and identifying whether the source interconnection is currently included in the model. It is a crucial step that minimises interaction with the client but can be time-consuming. An opportunity to automate this process is suggested.

Use the template for the information as defined by SCOR. Consider an opportunity to automate the process in further work (in step 4.1).

Experimenting with the way in which the question to discriminate between source process elements is asked

It was found that each input from a source process element was unique to a source actor and must be treated separately so that they could be discriminated against. It was first thought that the list could be consolidated with inputs being fed from multiple process elements. The nature in which an actor may implement a process element/generate an input may be different or is likely to have different interconnections, therefore, an entry needed to be created for each input generated from a source process element.

Discriminate between each entry for each interconnection in list (in step 4.2)

Experimenting with how information should be presented to distinguish between entries

It was initially considered useful to distinguish between core, promoted and simplified processes to speed up the process, provide more clarity and eliminate any duplication. This was not necessary as it was the combination of source process element and actor which were being discriminated

Use only a ‘yes’ or ‘no’ response when discriminating interconnections (in step 4.2)

The phase is complete when all source process elements have been discriminated. It should be completed in rounds for consistency.

The phase was completed in rounds, when no more data could be considered it indicated that the ‘candidates’ identified could be considered for inclusion in phase five. For purposes of consistency, the analysis had to be completed in rounds otherwise errors could occur.

Complete in rounds and be clear on the points of exit (point of exit)

255

Table A.5 Principle/observations when designing phase five Principle/observation Remarks from application Influence on the design

The phase is entered in successive rounds when candidate process elements have been described in phase four

It was more time-consuming and difficult to follow when considering each combination in turn with iteration between four and five. It also offered clarity when completed in rounds.

Enter in successive rounds when data is generated (point of entry)

The information is provided from phase four with no input necessary from the client. The information can be transferred relatively easily if the structure of the data is presented in both phases is common.

The previous step provides the necessary information. If this information is extracted in a common format then it makes the task very easy and straightforward.

Information is provided from phase four using a common format (in step 5.1)

Each decision includes a combination of the input, generated and fed by each candidate process element specified by actor

The inputs need to considered in terms of the process that generates it and the actor

List information in a common format that show input, process and actor (in step 5.1)

‘Having identified the immediate entry point of the experimental factors, and exit point of the responses, the modeller must then identify the key interconnections between these and the other components of the real world. Only the interconnections that are judged to be important, with respect to correctly interpreting the experimental factors and proving accurate values for the responses that need to be included in the model’ (Robinson, 2004 pg. 84)

The experimental factors concern the improvement and the responses, how the objectives are to be measured. The interconnections that need to be identified are between the core process elements that represent these and those in the supply setting.

The decision rule needs to reflect that the interconnections must provide a link between how the improvement is to achieve each objective (in step 5.2)

‘The scope of the model must be sufficient to provide a link between the experimental factors and the responses’ (Robinson, 2004 pg. 84)

There must be a link between the core process elements in the model.

As above

Each combination (input, candidate process and actor) can be considered for inclusion based upon one rule: Will the input to be generated from the candidate process element affect model behaviour by significantly impacting upon the objectives of study? If yes then ‘include’, if no then ‘exclude’, if unsure then ‘test’

Each decision is based upon the participants providing rationale for or against the input from the candidate process element having significant impact. It was observed that the process is one of learning, at the early stages models had to be thrown away but has more knowledge was gained there was less dependence on the ‘unsure’ decision. No testing was required on the final models as this is completed in phase 7.

Decisions need to be made based upon the input generated from the candidate and its impact on the objectives. Involves information being provided from the problem description (in step 5.2).

Each combination (input, candidate process and actor) that is to be included (has met rule one) can be considered for simplification based upon one rule: Can the input be generated in a simplified form (i.e. random distribution or fixed value), so that there are no further inputs to the process? If yes then ‘simplify’, if ‘no’ then promote.

It was found that an input did imply the boundary of the model. For this reason, some of the early learning’s were to do with inputs being simplified when the interconnection provided a significant link for an improvement to bring about change in the system and impact upon the objectives.

Only applicable to included combinations. Use a table format to enable the information to be shown and the decision to be reached (in step 5.2).

If the participants are unsure about a combination (input, candidate process and actor) then this can be tested using a prototyping method.

As with the above comment, it was observed that this decision was over-used when little knowledge about the supply system was understood. Later it was not used as all decisions could be made with confidence. It showed that clarification is needed with SMEs (if required).

Use a prototyping method when it is difficult to make a decision about the need to include a particular combination (in step 5.2)

256

Principle/observation Remarks from application Influence on the design

The decision is principally made by the modeller using SCOR descriptions of inputs and processes as a guide in light of the supply problem described. When the modeller is not able to make an independent decision (i.e. indicated ‘unsure’) then the necessary SMEs are consulted. Only when a valid and credible decision cannot be reached should there be a need to use a prototyping method.

The decision process was more focused and efficient. Decisions could be reached without the involvement of the client and it identifies the areas that needed clarification. It was a good aid to structure any interaction with the client. It also provided the information that is usually difficult and time consuming to obtain from the client. Situational information on the domain such as processes and relationships, which are described by SCOR.

Client is consulted when a decision cannot be made with the information available (in step 5.2)

A simplified input indicates the boundary of the model; it is fixed or generated as a sample distribution. There is no need to model the process that generates the input in any detail.

In the early stages when little knowledge of the problem existed it was common to attempt to over simplify the model. However, if something is simplified then this closes any further links.

Document a justification for each decision as a way of forcing the modeller to think through actions (in step 5.2)

Each decision is documented with rationale. This forces the participants to be clear why a particular decision was taken and the comments can be reviewed at a later stage, including validating the conceptual model.

When errors had occurred in earlier models any problems could be identified from the rationale and questioned. It was useful in validating the model in a later final step in phase five and in the validation phase.

Document any decisions made (in step 5.2)

A ‘promoted’ process element is included in the model so its interconnections between included processes and the immediate supply setting also need to be considered. In rounds, a list of promoted processes elements provides information so that the previous phase four can be re-entered.

Initiated the need to return to phase four. It was important to do this in successive rounds to avoid confusion and to minimise time.

Repeat phase four when a list of promoted elements have been identified, complete in rounds (in step 5.3)

The formulation of the model boundary effectively stops when there are no more decisions to be made (i.e. no more inputs to consider) and that there are no remaining promoted process elements to trigger the need to re-enter phase four.

Process stopped, but when process elements were suggested these were considered in phase four.

Include guidance on how the process stops (in step 5.3)

The decisions can be summarised in a simple table specified by actor and process for representing the processes in terms of those that are core, promoted and simplified; and for validation purposes. This table also helps as a quick reference guide to check if the process has been included or not.

A matrix of actors and processes with the decisions noted proved invaluable to aid in the analysis and for performing the check at the end of the phase.

List in the table each boundary decision specified by actor and process (in step 5.4)

There needs to be sufficient and correct linkages between the core processes included in the model and those included from within its supply setting; if there are any isolated process elements that have insufficient interconnections in the model then phase four and five needs to be repeated. The information provided on how each improvement is to achieve each objective will help identify the critical linkages between the core process elements.

A check could be implemented to show that the model is correct and as the sufficient links to demonstrate how each improvement is to bring about an impact upon each necessary objective.

Implement a check at the end of the phase to test the processes and interconnections in the model (in step 5.4)

If the list of processes and relationships are not sufficient and incorrect then it is necessary to review each of the decisions made to learn from the process and identify how the problem can be rectified.

In earlier stages, incorrect models were developed because of the over-dependence on the ‘test’ decision. This was improved as learning improved.

Phase four is re-entered after an attempt to identify any issues in the previous model which were a result of these decisions (in step 5.4)

257

Table A.6 Principle/observations when designing phase six Principle/observation Remarks from application Influence on the design

The actual practices should not be described until the model boundary has been formulated correctly

The actual practices cannot be determined if the processes and inputs have not been identified or the interconnections are incorrect.

The phase cannot be entered without the check being completed (point of entry)

The list of process elements within the boundary of the model, specified by status and actor can be extracted from phase five

Relatively straight-forward, can be completed using the matrix

Extract information from phase five (in step 6.1)

The actual practice can be described in sufficient detail by asking how the inputs (and sources) are to be converted to produce an output (to a destination), specified by each actor

The actual practices can be identified using SCOR process descriptions and practices when possible or they can be used as a guide when consulting SMEs for domain specific information. The practice determines what needs to be modelled.

Include a step that will aid in the description of the actual practice using information from SCOR and SMEs (in step 6.1)

The actual practice descriptions should be clear so that the relationships can be identified between practices and the actors that implement them

It was noted in both cases that the description needs to include the actors and describe the relationship between practices.

Make it clear in the steps that the actor and relationships between practices need to be described (in step 6.1)

Inputs and outputs to a process can be identified from the analysis presented when formulating the model boundary

Filters could be used in an excel spreadsheet to identify the inputs and outputs to a process. The filter can also include only ‘promoted’ and ‘simplified’ processes.

Use information from phase five on the inputs and outputs for each process (those included) (in step 6.1)

Processes that contain only a workflow input and no practices can be identified that would influence the characteristics of the workflow do not need to be modelled in any detail

A step was included to class some processes as ‘phantoms’; they do not need to be modelled in any detail but the linkage is critical.

Include a sub-step to identify ‘phantoms’ (in step 6.1)

The actual practices should be described for both the ‘AS-IS’ and ‘TO-BE’ supply system

All processes could be described and those that are included as ‘core’ for an improvement can indicate the changes in the ‘TO-BE’ system

Include a sub-step to describe both AS-IS and TO-BE practice (in step 6.1)

An actual practice can occur in more than one process; using the same description means that they can be consolidated

Practices appeared in more than one process in many cases, these were consolidated.

Include a sub-step for consolidating practices (in step 6.1)

The modelling components should be described using the terminology that is acceptable to the modeller

Using the terms model components could be used as a generic term

Identify the model components in generic terms (in step 6.2)

The assumptions and simplifications can be incorporated into the model component descriptions.

It was possible to aggregate components and reduce the rule set to represent a number of practices

Include a sub-step to identify ways in which to incorporate simplifications and assumptions into the model component descriptions (in step 6.2)

The point of exit is when all the actual practices have been described in enough detail. The validation procedure is considered in the final phase.

All actual practices could be represented by the components in the model. Although, the descriptions were dependent upon the modellers worldview and to an extent confidence (using experience) when incorporating simplifications and assumptions.

When all model components have been described. Validation occurs in the final step (point of exit)

258

Table A.7 Principle/observations when designing phase seven

Principle/observation Remarks from application Influence on the design

The phase is entered when the model components and their relationships have been described

It was deemed unnecessary to have a check in phase six as the final validation is comprehensive and checks the initial analysis first

From phase six when the model components, their relationships and the assumptions and simplifications incorporated into the model are described (point of entry).

Information is provided from the phases/steps that provide descriptions to create the conceptual model

Relatively straightforward and completed with ease

Obtain descriptions from previous phases/steps (in step 7.1)

It is necessary to validate the final model in case any new insights or learning has been identified during the process.

During early refinements models were thrown away due to new learning about the system

Validate the descriptions by performing previous checks (in step 7.2)

Previous checks can be redone; if any issues are identified then the user must return to that phase/step

Previous checks could be repeated, the entry and exit points were described

As above

No check is necessary of the inputs or boundary analysis in the final validation as they serve a purpose to aid in a description of actual practices

The input and boundary analysis do not provide relevant descriptions of the computer model. The information from these steps are incorporated in the descriptions of actual practices

N/A

A key question to be asked is: Does the conceptual model contain all the necessary details to meet the objectives of the simulation study? (Robinson, 2004, pg. 210)

This could be completed using an hypothesis test

Include an hypothesis test (in step 7.2)

The actual practices and their relationships can be examined with SME’s to determine whether the necessary details are sufficiently accurate to evaluate the means by which each improvement is to achieve each objective

Using the component list, the actual practices and their relationships can be discussed with SMEs. This could be circulated to the client and SMEs to obtain feedback or the modeller could offer a structured walkthrough of the model.

Include a check of the actual practices involving the client and SMEs. Be clear in the description different approaches to achieve this (in step 7.2).

The model components and relationships can be examined, to determine whether the conceptual model reproduces the actual practices and relationships

This could be completed by the modeller examining that the description of the simulation model to be developed represents the actual practices and relationships

Include an hypothesis test (in step 7.2)

The clients and SMEs should be involved in the validation of the conceptual model. Both the client (credibility) and modeller (validity) is interested in the accuracy of the model. E.g., whether the model is appropriate (Robinson, 2004, pg. 215).

The client understands the real world problem and the modeller role is to represent this appropriately in a simulation model. The client and SMEs understand deeply the actual system so they should be asked about the correctness and completeness of the list of actual practices and their relationships. The modeller will understand the simulation model so they should principally be involved in checking that the description of the model components and relationships reproduce the actual practices.

Be clear which steps are applicable to the different participants (in step 7.2).

An effective way to examine the relationships in a model is to represent the model using a graphical means (e.g. process flow diagram, logic flow diagram, activity cycle diagram).

Examples using process diagram identified that it would be easier to follow the flow and content of a conceptual model if it is represented graphically

Include an option if necessary to represent the conceptual model using a graphical means (in step 7.2).

Feedback should be sought on whether the model is appropriate from SMEs (Robinson, 2004, pg. 215)

SMEs can be useful when consulted on the actual practices but not necessarily the details of the model itself

Be clear which steps are applicable to the different participants (in step 7.2).

259

Principle/observation Remarks from application Influence on the design

The modeller and the clients should assess the assumptions and simplifications incorporated into the model for the level of confidence that can be placed in them and their likely impact on the accuracy of the model (Robinson, 2004, pg. 215)

Unlike the detail of the model the client should be able to understand why assumptions and simplifications should be included

Include a step to check the assumptions and simplifications with the client (in step 7.2).

Any judgements made when considering the assumptions and simplifications should help identify areas of potential concern (i.e. little confidence, which is believed to have a high impact, need to be addressed (Robinson, 2004, pg. 215)

Not able to comment, this would be useful as it pinpoints issues and ensures that they are addressed

If any issues arise, this warrants a return to a previously defined phase or stage (in step 7.2).

The final conceptual model is one which has been validated

Final model can be presented when it has been validated

Include a final documentation step (in step 7.3)

260

Appendix B Actual practice to be modelled (BeerCO development case)

Boundary setting status

Process element

Actor location

How is each process actually implemented in practice? (noting any practices that cannot be identified, but an input provides a

workflow)

AS-IS description for each process

TO-BE description for each process

CORE P2 Distributor

The distributor calculates the planned order quantity based on a rule (e.g. The wholesalers order = distributors purchase order. The distributor places an order that is as large as the wholesaler order).

Allow a human player to calculate the planned order quantity for the distributor role based on a rule. This rule should be experimented with to demonstrate how the visibility of the wholesaler current order, finished goods stock levels and incoming raw materials (crates of beer) influence the decision.

PROMOTED P2 Wholesaler

The wholesaler calculates the planned order quantity based on a rule (e.g. The retailers order = wholesaler purchase order. The wholesaler places an order that is as large as the retailers order)

No change

PROMOTED P2 Retailer

The retailer calculates the planned order quantity based on a rule (e.g. The external customer order = retailers purchase order. The retailer places an order that is as large as the customer’s order)

No change

CORE P4 Distributor

The distributor calculates how much beer to deliver to the wholesaler based upon rule (e.g. Distributor deliver to actual wholesaler order to the extent possible from the distributor available finished goods inventory)

Allow a human player to calculate the planned delivery quantity for the distributor role based on a rule. This rule should be experimented with to demonstrate how the visibility of the wholesaler current order, finished goods stock levels and incoming raw materials (crates of beer) influence the decision.

PROMOTED P4 Wholesaler

The wholesaler calculates how much beer to deliver to the retailer based upon rule (e.g. Wholesaler deliver to actual retailer order to the extent possible from available finished goods inventory)

No change

PROMOTED P4 Factory

The factory calculates how much beer to deliver to the distributor based upon rule (e.g. factory deliver to actual distributor order to the extent possible from available finished goods inventory)

No change

PROMOTED S1.1 Distributor

The distributor places an order based upon a rule (e.g. place distributor actual order = planned distributor order)

No change

PROMOTED S1.1 Wholesaler

The wholesaler places an order based upon a rule (e.g. place actual wholesaler order = planned wholesaler order)

No change

PROMOTED S1.1 Retailer

The retailer places an order based upon a rule (e.g. place actual retailer order = planned retailer order)

No change

SIMPLIFIED S1.1 External customer The customer places an actual order

No change

PROMOTED S1.2 Distributor Product is received at distributor goods inward location

No change

PROMOTED S1.2 Wholesaler Product is received at wholesaler goods inward location

No change

261

Boundary setting status

Process element

Actor location

How is each process actually implemented in practice? (noting any practices that cannot be identified, but an input provides a workflow)

AS-IS description for each process TO-BE

description for each process

PROMOTED S1.2 Retailer Product is received at retailer goods inward location No change

PHANTOM S1.3 Distributor No practice can be identified, the input provides a workflow No change

PHANTOM S1.3 Wholesaler No practice can be identified, the input provides a workflow No change

PHANTOM S1.3 Retailer No practice can be identified, the input provides a workflow No change

PROMOTED S1.4 Distributor Beer is received from the factory and stocked at the distributor goods receiving location

No change

PROMOTED S1.4 Wholesaler Beer is received from the distributor and stocked at the wholesalers goods receiving location

No change

PROMOTED S1.4 Retailer Beer is received from the wholesaler and stocked at the retailer goods receiving location

No change

PROMOTED P3 Factory Calculate the factory planned production quantity based on a rule (e.g. Works order = distributor order. The factory produces the amount of beer that is as large as the distributor order)

No change

PROMOTED M1.1 Factory The factory schedules production activities based upon rule (e.g. Produce actual factory work order = planned factory work order)

No change

SIMPLIFIED M1.2 Factory Infinite raw materials are available at the factory production No change

PROMOTED M1.3 Factory Beer is manufactured at the factory No change

PHANTOM M1.4 Factory No practice can be identified, the input provides a workflow No change

PROMOTED M1.5 Factory Beer is staged at goods inward awaiting movement to a finished goods location for a one week period

No change

PROMOTED M1.6 Factory The product is released to delivery No change

PROMOTED D1.2 Distributor Order is received from the wholesaler and entered into the distributor order processing system

No change

CORE D1.2 Wholesaler Order is received from retailer and entered into the wholesaler order processing system

No change

PROMOTED D1.2 Retailer Order is received from the external customer and entered into the retailers order processing system

No change

PROMOTED D1.3 Distributor

Inventory at the distributor is reserved to satisfy backorders first, followed by any new order received from the wholesaler. All unsatisfied wholesaler orders are added to the distributor backlog.

No change

CORE D1.3 Wholesaler Inventory at the wholesaler is reserved to satisfy backorders first, followed by any new order received from the retailer. All unsatisfied orders are added to the wholesaler backlog.

No change

PROMOTED D1.3 Retailer Inventory at the retailer is reserved to satisfy backorders first, followed by any new order received from the customer. All unsatisfied orders are added to the retailer backlog.

No change

PROMOTED D1.5 Factory Transportation is not constrained by load requirements No change

PROMOTED D1.5 Distributor Transportation is not constrained by load requirements No change

PROMOTED D1.5 Wholesaler Transportation is not constrained by load requirements No change

PHANTOM D1.6 Factory No practice can be identified, the input provides a workflow No change

PHANTOM D1.6 Distributor No practice can be identified, the input provides a workflow No change

PHANTOM D1.6 Wholesaler No practice can be identified, the input provides a workflow No change

PHANTOM D1.7 Factory No practice can be identified, the input provides a workflow No change

PHANTOM D1.7 Distributor No practice can be identified, the input provides a workflow No change

PHANTOM D1.7 Wholesaler No practice can be identified, the input provides a workflow No change

CORE D1.8 Factory Product is received from the factory production and provides the factory finished goods inventory level for calculation of the inventory metric

No change

CORE D1.8 Distributor Product is received from the distributors goods receiving and provides the distributors finished goods inventory level for calculation of the inventory metric

No change

CORE D1.8 Wholesaler Product is received from wholesalers goods receiving and provides the wholesaler finished goods inventory level for calculation of the inventory metric

No change

CORE D1.8 Retailer Product is received from the retailers goods receiving and provides the retailers finished goods inventory level for calculation of the inventory metric

No change

262

Boundary setting status

Process element

Actor location

How is each process actually implemented in practice? (noting any practices that cannot be identified, but an input provides a workflow)

AS-IS description for each process TO-BE description for each

process

PROMOTED D1.9 Factory Factory satisfies all orders placed by the distributor No change

PROMOTED D1.9 Distributor Distributor satisfies all orders placed by the wholesaler

No change

PROMOTED D1.9 Wholesaler Wholesaler satisfies all orders placed by the retailer

No change

PROMOTED D1.10 Factory The factory moves finished goods to stocking location

No change

PROMOTED D1.10 Distributor The distributor moves finished goods to stocking location

No change

PROMOTED D1.10 Wholesaler The wholesaler moves finished goods to stocking location

No change

PROMOTED D1.11 Factory The factory places beer onto transportation No change

PROMOTED D1.11 Distributor The distributor places beer onto transportation No change

PROMOTED D1.11 Wholesaler The wholesaler places beer onto transportation No change

PROMOTED D1.12 Distributor The product (beer) is shipped from the distributor to the wholesaler goods inward stock location

No change

CORE D1.12 Wholesaler The product (beer) is shipped from the wholesaler to the retailer goods inward stock location

No change

PROMOTED D1.12 Factory The product (beer) is shipped from the factory to the distributor goods inward stock location

No change

CORE D1.13 Wholesaler The wholesaler tracks the completeness of the order to produce in the "in-full" aspect of the metric

No change

PROMOTED D1.13 Factory The beer supplied by the factory is received by the distributor

No change

PROMOTED D1.13 Distributor The beer supplied by the distributor is received by the wholesaler

No change

SIMPLIFIED ED.4 Retailer There are no safety stocks calculated No change

SIMPLIFIED ED.4 Distributor There are no safety stocks calculated

The distributor (human) may wish to calculate how much safety stock is needed to satisfy demand.

SIMPLIFIED ED.4 Wholesaler There are no safety stocks calculated No change

SIMPLIFIED ED.4 Factory There are no safety stocks calculated No change

SIMPLIFIED EP.3 Factory The factory planning data is collected for manufacturing, resource and delivery

No change

SIMPLIFIED EP.3 Distributor The distributor planning data is collected for manufacturing, resource and delivery

No change

SIMPLIFIED EP.3 Wholesaler The wholesaler planning data is collected for manufacturing, resource and delivery

No change

SIMPLIFIED EP.3 Retailer The retailer planning data is collect for manufacturing, resource and delivery

No change

SIMPLIFIED ES.4 Distributor The distributor maintains the goods receiving stocking location and target levels

No change

SIMPLIFIED ES.4 Wholesaler The wholesaler maintains the goods receiving stocking location and target levels

No change

SIMPLIFIED ES.4 Retailer The retailer maintains the goods receiving stocking location and target levels

No change

SIMPLIFIED ED.1 Factory

Rules are maintained for the factory which affect the acceptance of an order from the distributor based on quantity (i.e. orders can range between 0 - 99 barrels of beer)

No change

SIMPLIFIED ED.1 Distributor Rules are maintained for the distributor which affect the acceptance of an order from the wholesaler based on quantity

No change

SIMPLIFIED ED.1 Wholesaler Rules are maintained at the wholesaler which affect the acceptance of an order from the retailer based on quantity

No change

SIMPLIFIED ED.1 Retailer Rules are maintained at the retailer which affect the acceptance of an order from the customer based on quantity

No change

263

Appendix C Actual practice to be modelled (CarCO development case)

Status Process element

Actor location

How is this actually implemented in practice? (noting any practices that cannot be identified, but an input provides a workflow)

AS-IS TO-BE

CORE P2 LA

The daily call in (DCI) is generated by the LA materials management (MM) system each day and sent to the schedule product deliveries and LA production process. The DCI gives a 10-day horizon of daily requirements and tentative weekly and monthly forecasts.

The daily call in (DCI) is generated by the LA each day and sent directly to the CHR and T delivery planning process and enters the LA production process

PROMOTED P2 SS The SS Material requirements plan (MRP) is used to plan blanket orders sent to CHR and T

No change

PROMOTED P3 CHR The CHR re-plan "production" kanbans and manufacturing resources

No change

PROMOTED P3 T The T re-plan "production" kanbans and manufacturing resources

No change

PROMOTED P3 SS The SS produces to DCI (each day with a 10 day horizon) received from the LA

Blanket purchase orders for CHR and T over multiple delivery dates scheduled to cover period requirements

PROMOTED P3 LA

The target launch sequence (TLS) is generated for a seat set (including tracks and central headrest) by the LA stores and controls (S&C), stating the actual daily demand in production line sequence for the painted car bodies.

No change

CORE P4 CHR The CHR re-plan "move" kanbans and transport resources

CHR adjust their kanban set-up to reflect daily call in (DCI) requirements

CORE P4 T The T re-plan "move" kanbans and transport resources

T adjust their kanban set-up to reflect daily call in (DCI) requirements

PROMOTED P4 SS The SS delivers to TLS (forecast of daily requirements) received from the LA

No change

CORE S1.1 LA Target launch sequence (TLS) is continuously broadcast from the LA to SS and the DCI to the SS material requirements planning system

Target launch sequence (TLS) is continuously broadcast from the LA to SS and the DCI to the SS material requirements planning system. Also, the DCI is sent to the CHR and T planning system

PROMOTED S1.1 3PL The 3PL 2-bin system based on gating mechanism is used to notify CHR and T of the need to deliver product (electronic kanban cards)

No change

CORE S1.2 LA

Seat sets are delivered to the LA point of use (POU) at line side by the SS supplier. The "% orders/lines received on-time to demand requirement" metric is calculated by dividing the number of orders received on time to demand requirements divided by total orders in measurement period.

No change

PROMOTED S1.2 3PL Product (CHR and T) is received daily at the 3PL warehouse

No change

PHANTOM S1.3 3PL No practice can be identified, the input provides workflow

No change

PHANTOM S1.4 3PL No practice can be identified, the input provides workflow

No change

PROMOTED M1.1 CHR CHR schedules production, using demand-pull production kanban mechanism (kanban from S1.1 at 3PL)

No change

PROMOTED M1.1 T T schedules production, using demand-pull production kanban mechanism (kanban from S1.1 at 3PL)

No change

PROMOTED M1.1 SS The SS produces to DCI (each day with a 10 day horizon) received from the LA

No change

264

Status Process element

Actor location

How is this actually implemented in practice? (noting any practices that cannot be identified, but an input provides a workflow)

AS-IS TO-BE

PROMOTED M1.1 LA Target launch sequence (TLS) is continuously broadcast from the LA to SS

No change

PROMOTED M1.2 SS SS Issue material based on 2-bin system from 3PL local stock

No change

SIMPLIFIED M1.2 CHR The CHR assumes infinite raw materials available to produce central headrests

No change

SIMPLIFIED M1.2 T The T assumes infinite raw materials available to produce tracks

No change

PROMOTED M1.3 CHR Central head rests are produced and tested using demand-pull mechanisms

No change

PROMOTED M1.3 T Tracks are produced and tested using demand-pull mechanisms

No change

PROMOTED M1.3 SS SS assembles and tests rear seats and front seats from line side stock (tracks and central headrests) using demand-pull mechanisms

No change

PROMOTED M1.4 CHR CHR are packaged to minimise damage in transit to SS

No change

PROMOTED M1.4 T T are packaged to minimise damage in transit to SS

No change

PROMOTED M1.4 SS SS are covered in protective sheeting to minimise damage in transit to LA

No change

PROMOTED M1.5 CHR Kanban controls the movement of CHR No change

PROMOTED M1.5 T Kanban controls the movement of T No change

PROMOTED M1.5 SS SS are staged awaiting collection for delivery to POU at LA line-side location for seat sets

No change

PROMOTED M1.6 CHR Kanban controls the movement of CHR No change

PROMOTED M1.6 T Kanban controls the movement of T No change

PROMOTED M1.6 SS SS are staged awaiting collection for delivery to POU at LA line-side location for seat sets

No change

PROMOTED D1.2 CHR Receive kanban replenishment signal for CHR from the 3PL

No change

PROMOTED D1.2 T Receive kanban replenishment signal for T from the 3PL

No change

PROMOTED D1.2 SS The SS receives a signal based on the TLS No change

PROMOTED D1.3 CHR Kanban controls the movement of CHR No change

PROMOTED D1.3 T Kanban controls the movement of T No change

PROMOTED D1.3 SS Seat sets are sequenced based on the TLS provided by LA

No change

PROMOTED D1.4 CHR Kanban controls the movement of CHR No change

PROMOTED D1.4 T Kanban controls the movement of T No change

PROMOTED D1.4 SS Seat sets are sequenced based on the TLS provided by LA

No change

PROMOTED D1.5 CHR Kanban controls the movement of CHR No change

PROMOTED D1.5 T Kanban controls the movement of T No change

PROMOTED D1.5 SS Seat sets are sequenced based on the TLS provided by LA

No change

PROMOTED D1.6 CHR CHR are transported daily to the 3PL warehouse No change

PROMOTED D1.6 T T are transported daily to the 3PL warehouse No change

PROMOTED D1.6 SS SS are transported to LA POU in production line-side location

No change

PHANTOM D1.7 CHR No practice can be identified, the input provides workflow

No change

PROMOTED D1.9 SS SS are transported to LA POU in production line-side location

No change

265

Status Process element

Actor location

How is this actually implemented in practice? (noting any practices that cannot be identified, but an input provides a workflow)

AS-IS TO-BE

PROMOTED D1.8 CHR CHR is received from make in loading area for 3PL pick up. Product receipts are recorded.

No change

PROMOTED D1.8 T T is received from make in loading area for 3PL pick up. Product receipts are recorded.

No change

PROMOTED D1.8 SS Seat sets are received from make and put-away in SS warehouse. Product receipts are recorded.

No change

PHANTOM D1.9 CHR No practice can be identified, the input provides workflow No change

PHANTOM D1.9 T No practice can be identified, the input provides workflow No change

PHANTOM D1.9 SS No practice can be identified, the input provides workflow No change

PHANTOM D1.10 CHR No practice can be identified, the input provides workflow No change

PHANTOM D1.10 T No practice can be identified, the input provides workflow No change

PHANTOM D1.10 SS No practice can be identified, the input provides workflow No change

PHANTOM D1.11 CHR No practice can be identified, the input provides workflow No change

PHANTOM D1.11 T No practice can be identified, the input provides workflow No change

PROMOTED D1.11 SS Seats sets are loaded in sequence No change

PROMOTED D1.12 3PL 3PL ships central headrests and tracks to SS No change

PROMOTED D1.12 SS Seat sets are shipped to POU at LA manufacturing location No change

PHANTOM D1.13 3PL No practice can be identified, the input provides workflow No change

PHANTOM D1.14 SS No practice can be identified, the input provides workflow No change

PROMOTED EP.3 CHR Manufacturing, resource and delivery data No change

PROMOTED EP.3 T Manufacturing, resource and delivery data No change

PROMOTED EP.3 SS Record DCI and TLS requirements No change

PROMOTED EP.3 LA Supply chain execution information is recorded No change

PROMOTED ED.4 SS SS maintains finished goods, and inventory levels for product mix No change

PROMOTED ED.4 CHR CHR maintains finished goods, and inventory levels for product mix No change

PROMOTED ED.4 T T maintains finished goods, and inventory levels for product mix No change

266

Appendix D Illustrations of model components to be developed into a computer model Table D.1 Model components for ‘Retailer plan and place order’ (BeerCo development case)

AS-IS/ TO-BE

Actor that implements

practice List of consolidated actual practices

How will each actual practice be represented by the components in the computer model?

What processes, activities or events need to be included in the computer model?

What entities need to be included to represent the activities or events in the computer model?

Comment on any assumptions or simplifications

from 6.1 From 6.2.1 From 6.2.2 From 6.2.3

AS-IS

Retailer

The retailer calculates the planned order quantity based on a rule (e.g. The external customer order = retailers purchase order. The retailer places an order that is as large as the customer’s order)

1. Retailer player makes a decision on how much to order from the wholesaler in the next period using available planning data. A purchase order is created (Retailer_order) with the order qty (Retailer_Order.qty) and date (Retailer_Order.date) set on the retailer purchase order

Human player (retailer role): The player exists in the ‘world’ entering the process to plan order in each decision period

Planning data to make decision: Retailer_warehouse: Units of beer (stock) on hand in warehouse (Retailer_warehouse.AVAILinv); ExCustomer_order: Units of beer ordered from the external customer (ExCustomer_order.qty); Retailer.on_order: Product on order with the wholesaler; Retailer_order: Purchase order with order qty (Retailer_Order.qty) and date (Retailer_Order.date)

Orders are planned in each weekly decision period

AS-IS

Retailer The retailer places an order based upon a rule (e.g. place actual retailer order = planned retailer order)

1. Retailer player places an order for each decision period 2. Accept order if within max order size? 3. If yes, (the order size is within the max order size) then the

order is accepted 4. If no, (the order size is not within the max order size) then

the player is informed that the order cannot be permitted. The rejected order is displayed and the retailer player re-enters the order.

5. If order is accepted an accepted order is sent to the wholesaler ‘receive order’ process

Human player (retailer role): The player exists in the ‘world’ entering the process to place an order in each decision period; Retailer_order: Retailers purchase order for units of beer. There is a maximum order quantity that cannot be exceeded (Retailer_order.max).

Orders are placed in each weekly decision period; All orders placed are accepted if within the max order size

AS-IS

Retailer

Rules are maintained at the retailer which affect the acceptance of an order from the customer based on quantity (i.e. orders can range between 0 - 99 barrels of beer)

N/A N/A

Include order acceptance rule based on order max size in place order

267

Table D.2 Model components for ‘Wholesaler Receive and fulfil order’ (BeerCo development case) AS-IS/ TO-BE

Actor that implements

practice

List of consolidated actual practices from 6.3.2

How will each actual practice be represented by the components in the computer model?

What processes, activities or events need to be included in the computer model?

What entities need to be included to represent the activities or events in the computer model?

Comment on any assumptions or simplifications

from 6.1 From 6.2.1 From 6.2.2 From 6.2.3

AS-IS

Wholesaler Order is received from retailer and entered into the wholesaler order processing system

1) Receive and add current order from Retailer (Retailer_order) into a queue in date order

2) Check to see if any backorders remain (Wholesaler_backorder>0) and create Wholesaler_onorder. It is calculated: Wholesaler_onorder = Retailer_order.qty + Wholesaler_backorder

3) Is inventory available? (Wholesaler_Warehouse.AVAILinv>0) 4) If yes (inventory is available), Calculate how much of the order

can be satisfied and create delivery order. It is calculated: Wholesaler_deliveryorder = Min (Wholesaler_warehouse.AVAILinv; Wholesaler_onorder) a) Can the order be satisfied in full?

i) If yes then, Order is complete

ii) If no then, Create an unsatisfied order as only part of the order is satisfied (Wholesaler_order.unsatisfied = Wholesaler_onorder – Wholesaler_deliveryorder)

iii) Update backorder status (Wholesaler_backorder = Wholesaler_order.unsatisfied)

5) If no (inventory is not available), the update backorder status as order cannot be met (Wholesaler_backorder = Wholesaler_onorder)

Retailer_order: An order from the retailer for units of beer (Retailer_order.qty) for a given date (Retailer_order.date); Wholesaler_backorder: Orders that have yet to be satisfied from available inventory; Wholesaler_Warehouse: The units of beer available in Wholesaler warehouse (Wholesaler_Warehouse.AVAILinv); Wholesaler_deliveryorder: Units of beer to be delivered in period; Wholesaler_order: Unsatisfied wholesaler order (Wholesaler_order.unsatisfied)

All orders received are accepted; orders are received in each one week period; The order is delayed by 1 week

AS-IS

Wholesaler

Inventory at the wholesaler is reserved to satisfy backorders first, followed by any new order received from the retailer All unsatisfied orders are added to the wholesaler backlog.

N/A N/A

Assume inventory management is part of the receive and fulfil process

268

Appendix E Example process flow diagrams for the BeerCo development case

Retailer player makes a decision on how much to order from the wholesaler in the next period using available planning data. A purchase order is created

(Retailer_order) with the order qty (Retailer_Order.qty) and date (eRetailer_Order.date) set on the retailer purchase order

Planning data:Retailer_warehouse.AVAILinv;ExCustomer_order.qty;Retailer.on_order

Purchase order:Retailer_order

Player:Human player (retailer role)

Player:Human player (retailer role)

World

To Wholesaler ‘receive order’

Retailer player places an order for each decision period

Accept order if within max order size?

The player is informed that the order cannot be permitted

NoYes

The order is accepted

An order is sent to the wholesaler ‘receive order’ process

Reject orderRetailer_order

Retailer_order

Retailer_order

Accepted orderRetailer_order

Retailer max order qty:Retailer_order.max

W1

Figure E.1 Retailer plan and place order in BeerCo development case

269

Check to see if any backorders remain (Wholesaler_backorder>0) and create Wholesaler_onorder

Wholesaler_onorder = Retailer_order.qty + Wholesaler_backorder

Receive and add current order from Retailer (Retailer_order) into a queue in date order

Retailer_order

Yes

From Retailer plan and place

Available inventory in Warehouse:Wholesaler_Warehouse.AVAILinv

Retailer’s order:Retailer_order.qtyRetailer_order.date

Yes No

Is inventory available?

Wholesaler_Warehouse.AVAILinv>0

Calculate how much of the order can be satisfied and create delivery order

Wholesaler_deliveryorder = Min (Wholesaler_warehouse.AVAILinv;

Wholesaler_onorder)

Create an unsatisfied order as only part of the order is satisfied

(Wholesaler_order.unsatisfied =Wholesaler_onorder –

Wholesaler_deliveryorder)

No

Update backorder status as order cannot be met

Wholesaler_backorder = Wholesaler_onorder

Order is complete

Yes No

Update backorder status(Wholesaler_backorder =

Wholesaler_order.unsatisfied)

eWholesaler_order Wholesaler_order.unsatisfied

Wholesaler_onorder

Wholesaler_backorder

Current order:Wholesaler_onorder

Can the order be satisfied in full?

Terminate

Wholesaler backorder:Wholesaler_backorder

Wholesaler_backorder

Wholesaler_deliveryorder

Backorder status

Figure E.2 Fulfil order in BeerCo development case

270

Appendix F Flowchart of the CoffeePotCo computer simulation model

Figure F.1 Flowchart of computer simulation program for CoffeePotCo

Source: Taylor et al., (2008, pg. 5)

271

Appendix G Comparison of practice to be modelled and CoffeePotCo computer model Table G.1 AS-IS Scenario in CoffeePot Co validation case for the ‘Customer’

Actual practice to be modelled Representation in computer model Comments on any omissions or differences

Outcome from 6.1 in the SCM2 From Taylor et al., (2008)

The customer sends an order with no prior notice or schedule to the warehouse

An activity “determines demand”. Demand is normally distributed and that inter-arrival time for demand is exponentially distributed (Poisson arrivals).

Not significant, orders are sent continuously and independently of one another.

272

Table G.2 AS-IS Scenario in CoffeePotCo validation case for the ‘Warehouse’

Actual practice to be modelled Representation in computer model Comments on any omissions or differences Outcome from 6.1 in the SCM2

From Taylor et al., (2008)

The warehouse determines whether or not to place an order with the factory for finished goods replenishment using an (R, r) policy.

The model (“Reach Re-order point?”) determines whether an order should be placed for finished goods replenishment using an (R,r) policy. If the inventory position is insufficient (current finished goods inventory plus on order), an order is placed to move to final goods inventory position to R, which is established as r+EOQ, where EOQ is the economic order quantity.

No difference

The re-order (r) point is adjusted to obtain a desired service level. A user manipulates the re-order point (r) to obtain a desired service level No difference, The re-order point is a user input.

The warehouse ships the complete or partial order to the customer once the finished goods is available

Ships when inventory is available, either complete or partial. Backorders when insufficient stock is available.

No difference

The product (coffee pots) is received at the warehouse from the factory.

The product arrives at finished good stock from the factory; the time is included in the „shipping delay‟.

No difference, the model detail is reduced by aggregating the activity with the „delay for shipping‟.

The warehouse receives the actual order from the customer. All orders are accepted.

Orders are received according to a demand inter-arrival time. No difference

The warehouse inventory is identified and reserved to satisfy all or part of demand for a specific delivery date. The remaining orders are backlogged, placed on a backorder status to be fulfilled as production is completed and products arrive at finished goods stock.

The order is satisfied from finished goods if possible. If not the remainder is added to backorders. As new supplies arrive, backorders are satisfied first.

No difference

The delivery (the works orders) to the warehouse are accumulated until the shipment quantity is reached

Product is batched for shipment according to the shipment method when product completes manufacturing.

No difference

The product is received from the factory. The value of finished goods stock is calculated to fulfil part of the 'Inventory days of supply' metric.

Product arrives directly to finished good stock. Value of finished goods stock is calculated.

Not significant, the route is simplified (direct to finished goods stock)

The product is shipped to the customer The order is terminated when orders have been satisfied. No difference

The product is received from the warehouse to the customer location. The satisfaction of this commitment (total number of orders delivered) is needed to calculate delivery performance to customer commit date.

Orders are “satisfied until supply is exhausted”, the orders are supplied outside of the model (represented as a sink); The delivery performance is reviewed when the reorder point (r) is adjusted.

Not significant, delivery performance is calculated by manipulating the reorder point to obtain a desired service level.

273

Table G.3 AS-IS Scenario in CoffeePotCo validation case for the ‘Factory’ Actual practice to be modelled Representation in computer model

Comments on any omissions or differences Outcome from 6.1 in the SCM2

From Taylor et al., (2008)

The factory delivery plan, factory production plan and factory production schedule = the actual order from the warehouse

The model is actualised by entities representing demand (actual order)

No difference

Assume raw materials are available to factory production process

Assumed raw materials are available infinitely Not significant, raw materials are available

The coffee pots are manufactured on a manufacturing line with specified cycle time and number of stations.

The “production delay” is based upon number of units that can be produced in a week with an assumed number of operators/stations available at the facility.

Not significant, production delay included

The factory 'make' processes holds made to order coffee pots to await shipment per associated order from the warehouse. The move transaction is part of the deliver process.

Time included in “production delay”. Not significant, included in the production delay

The factory collects the next works order from production

It is assumed that the factory produces based upon satisfying the next order in queue.

Not significant, next order collected

The factory loads the product onto the ship or aircraft depending upon the option

The product is loaded depending upon shipment method constraints (e.g. container size varies between ship and aircraft)

Not significant, product is loaded dependent on shipping method

The product is shipped to the warehouse from the factory

A complete order is shipped (“Delay for shipping”) from the factory in a specified time and at a specified cost. The shipping costs and time estimates are taken from Zeng (2003).

No difference, the transportation lead-time is taken from Zeng (2003, pg. 372). In this case, the „Water-truck full container load‟ is selected. The time begins with consolidation, involves the transfer of the consolidated goods to the seaport by truck, storage in warehouses, loading, actual transit, unloading, customs clearance, transfer to the destination, and ends with receiving.

The product is received from the factory to the warehouse location.

Moves directly to finished good stock Not significant, product is received at the warehouse

274

Table G.4 TO-BE Scenario in CoffeePotCo validation case for the ‘Factory’

Actual practice to be modelled Representation in computer model Comments on any omissions or differences

Outcome from 6.1 in the SCM2 From Taylor et al., (2008)

The factory consolidate orders to suit container size

Yes, orders are consolidated to suit container size. Not significant

The factory collects orders from production for each container load

Yes, orders are collected in the desired amount (“large” in this case) depending upon shipping method.

Not significant

The factory packs the container, the time taken is dependent on container size

Packing time is not included. Significant, the packing time has not been included. This would vary depending upon shipping method and container size.

275

Appendix H Evaluation of how information is used and provided in the preliminary validation case

Table H.1 Evaluation of how the SCM2

uses information

Ph. Information required by the SCM2 Information provided by the

SCM2 Comments on following the steps in the SCM2 for the CoffeePotCo validation case

1

Objective of study

Supply chain improvements

Supply chain problem setting

Means by which each improvement is to achieve each objective

Description of the supply chain problem (objective, improvement and setting) checked to establish that the improvement(s) selected will bring about change to achieve the set objective(s)

The client was the modellers that conducted the simulation study; the requirements were presented in Taylor et al., (2008). The SCOR model was used to refine how to define the necessary objectives, describe the improvements. The supply setting was extracted from the discussion in the paper of the experimental plan and tools. The SCOR model was also useful to check that the improvement(s) selected will bring about change to achieve the set objective(s) using the detailed descriptions. In particular, the practice guide suggested their potential impact on SCOR performance metrics. This is not the case for all SCOR practices.

2

Metrics associated with each performance attribute (distinguished by level)

Calculation for each metric

Processes that provide a data source

Actor associated with each data source

Measurement span

Hierarchy of supply chain performance metrics to measure each objective

List of calculations and data source requirements for each metric

The SCOR model is utilised by the modeller to translate the description of the objective of study provided in phase 1, into the necessary metrics to evaluate performance. The remaining inputs were necessary in order to drive the proceeding analysis to determine what to include in the model. There was an issue when using SCOR to identify the data sources for the ‘Inventory days of supply’ metric. It was adequately described but the data requirements are not specified for this metric as it is captured by existing business operating systems (e.g. general ledger system). Information is ‘calculated’ by importing data from these systems and transferring them into the prescribed analytics/information (SCOR V.9, section 2.5.2).

3

Level of process detail for each supply chain improvement option

Actor

Processes and descriptions for level 1 top level (process types); level 2 configuration (process categories); and level 3 process elements (decomposed processes) for each actor

As above the SCOR practice guide was used to identify the process types associated with each improvement identified in phase one. One of the advantages noticed in the discussion of the benefits of utilising SCOR is that it has a range of predefined business practices that have associated process elements. In this case, there was not a predefined set of practices associated for the size of shipment quantities (although for evaluating shipment method there is several options). The process framework was used to identify that it is the delivery processes associated with picking, packing, shipping and receiving the order to the Warehouse that the change would be implemented.

276

Ph. Information required by the SCM2 Information provided by the

SCM2 Comments on following the steps in the SCM2 for the CoffeePotCo validation case

4

Information supplied from phase two and three on the core process elements

Inputs and source process elements associated with each process element included in the model

List of inputs to each process element included in the model and their source process elements

List of candidate process elements for possible inclusion in the model

For each of the process elements noted as core, the associated inputs could be obtained from the SCOR model. This was a relatively easy task, but tedious and an area where mistakes could be made. However, this could be made redundant in a methodology by automating it when a decision is made in phase five. One of the problems identified was that SCOR v.9 was designed to be generic, when previous versions had included richer and detailed process maps and the interconnections were much more focused. There were some mistakes identified between SCOR v.9 and v.8, which meant that a workbook was created to help perform this analysis.

5

Information from 4.2.1 and 4.2.2 (list of candidate process elements), list of inputs from 4.1.1, and actors from 2.2 and 3.2

Use of SCOR descriptions of process elements and inputs to aid in deciding on the status whether to include a process or not, or even simplify

List of PROMOTED, SIMPLIFIED, TO TEST, or EXCLUDED process elements (with justification)

Above are verified

The information provided by SCOR on the processes and inputs were used to make the decision. These decisions were made by following the two rules embedded into the steps. It was often the case in the case that a lot of the decisions were a result of subjective opinion, leading to many revisions. The benefit of the process was that it was a structured approach that aids a user to make the necessary decisions comprehensively using a predefined supply chain process framework developed and tested in industry. Any errors that were made could easily be traced when the final check was made (especially when each decision is justified and documented). The issue that resulted from any revisions included the need to adjust or even repeat phase four.

6

Process elements within the model boundary, by status and actor (from phase 5)

Decide on ‘phantom’ process elements

Description of actual practice (later consolidated)

Description of how each actual practice

Description of how each actual practice is converted into the model components; interconnections between components; and simplifications and assumptions

Processes treated as ‘phantoms’

Consolidated list of actual practices to be modelled

Consolidated list of actual practices to be modelled

The steps were easy to follow. Some questions were raised about the computer model developed for this case and the descriptions provided for the actual practices. The process elements that were described as CORE for the improvement being implemented was actually simplified in the computer model by having a time delay for shipping (including associated times for picking, packing, loading etc.,). As there is only one workflow to these activities (the product), a judgement was made and justified that the process ‘adds’ value (is significant) but these activities were actually simplified.

7

Description of the purpose and objectives of the simulation model to be developed; improvements; performance measures; actual practice and how each will be represented by the components in the model and their interconnections; assumptions and simplifications

Checks are conducted by the modeller utilising the SCOR model and with interaction with the client

Draft and validate a non-software specific description of the simulation model to be developed

Issues that have arisen in the validation steps

Not evaluated

277

Appendix I Issues for testing the ‘usability’ of the SCM2

Table I.1 Issues for testing the ‘usability’ of the SCM

2

Observations from applying the SCM2 to the CoffeePotCo validation case Issues for future refinement and testing

Clarity

Methodology follows a structure that includes a procedure with associated information requirements and the information provided

The points of entry and exit are defined for each phase and step

Structured to utilise the domain knowledge of SCOR, this included adding the actors when describing process elements

A validation procedure is incorporated in the methodology and at the final stage

Structure allows for iteration between stages, in particular when validating the output from steps (these are defined)

The terms used in the methodology use common simulation language (e.g. model components) that is generic for the simulation approaches described and using SCOR terminology

Clarity of the overall structure, each phase, steps within each phase, information required and provided for each step using diverse users. It would be interesting to study both expert and novice users.

Development of a guide that includes the necessary terms for use in a simulation project (e.g. many actors modelled in a supply chain)

Ease of use

The steps could be followed to achieve each of the information that the SCM2 should provide from the available information

The steps could be followed to arrive at the actual practices to be modelled within the boundary of the supply problem

As above, but further work is needed to assess the overall methodology including how the methodology aids a user to design the model components in the model and validation

Appropriateness

Methodology has been defined to meet a set of requirements for conceptual modelling in SCM applications and builds on existing conceptual modelling practice

The methodology incorporates both novel concepts for conceptual modelling of SCM applications and utilises existing practice

It would be useful to compare how experts and novice users may benefit from the methodology. This includes any improvement in time, using resources, focus of interaction between the stakeholders in the project, documentation of the conceptual model and any decisions made and comprehensiveness of the information provided.