Supply chain management, conceptual modelling, simulation, performance evaluation ...... used as a specific means for representing discrete-event simulation models (Hill, 1971) and have ...... metric, 'AM.2.8 Inventory: capital employed in finished goods stock'. ...... Oak Brook, IL: Council of Logistics Management. BROOKS ...
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. 1
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 2
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
3
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 MedinaLopez (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.
4
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
5
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.
6
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 7
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 8
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 9
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
10
List of figures in thesis Figure 1.1 Figure 2.1 Figure 3.1 Figure 6.1 Figure 7.1 Figure 7.2 Figure 7.3 Figure 7.4 Figure 7.5 Figure 7.6 Figure 7.7 Figure 7.8 Figure 7.9 Figure 7.10 Figure 7.11 Figure 7.12 Figure 7.13 Figure 7.14 Figure 7.15 Figure 7.16 Figure 7.17 Figure 8.1 Figure 8.2 Figure 8.3 Figure 8.4 Figure E.1 Figure E.2 Figure F.1
Overview of the thesis structure and research programme .................................... 20 Classification of supply chain simulation approaches.............................................. 34 Overview of research programme ........................................................................... 64 Example of SCOR inputs and outputs to a decomposed business process............ 124 Overview of the SCM2 ............................................................................................ 133 Structure and flows in the BeerCo development case........................................... 137 A simplified diagram of CarCo’s supply chain ........................................................ 138 ‘Reliability’ metric structure with an example of a level 3 metric ......................... 147 Calculation and data collection needs for RL.2.1 % of orders delivered in full ..... 148 Extract of the SCOR descriptions of best practices ................................................ 151 Example of the inputs of a source process element described in SCOR ................ 154 Process elements, inputs, source process element and suggested source actor .. 155 Extract of the list of inputs considered for S1.1 in the CarCo development case . 156 Extract of how phase four was completed for the CarCo development case ....... 157 Extract of the output from phase four that is transferred (in step 5.1) ................ 160 Extract of phase five from the BeerCo development case for the Wholesaler ..... 163 Template used to check the linkages between processes in the CarCo development case......................................................................................................................... 165 Tracing back the inputs of included processes from a data source ....................... 166 ‘Phantoms’ in the CarCo development case (inputs shown for D1.10 SS) ............ 168 Extract of actual practice descriptions in the BeerCo development case ............. 169 Extract of how actual practices can be ‘consolidated’ for the CarCo development case......................................................................................................................... 170 Graphical illustration of CoffeePotCo supply problem .......................................... 185 Interconnection identified for each process element in the model ...................... 190 Formulation of the model boundary (CoffeePotCo) .............................................. 191 Promoted, core and simplified process elements for the CoffeePotCo validation case......................................................................................................................... 194 Retailer plan and place order in BeerCo development case .................................. 268 Fulfil order in BeerCo development case ............................................................... 269 Flowchart of computer simulation program for CoffeePotCo ............................... 270
11
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 12
Table 8.3 Table 8.4 Table 8.5 Table 8.6 Table 8.7 Table 8.8 Table 8.9 Table 8.10 Table 8.11 Table 8.12 Table 9.1 Table 9.2 Table 9.3 Table 9.4 Table A.1 Table A.2 Table A.3 Table A.4 Table A.5 Table A.6 Table A.7 Table D.1 Table D.2 case) Table G.1 Table G.2 Table G.3 Table G.4 Table H.1 Table I.1
Statement of how each process represents each improvement (CoffeePotCo) ....... 189 Promoted process elements and simplified inputs (CoffeePotCo) ............................ 192 Candidate process elements promoted in each round (CoffeePotCo)....................... 193 Summary of the feasibility criteria to be examined ................................................... 195 Summary of the utility criteria to be examined ......................................................... 196 Key observations from an analysis of the information requirements for the SCM2 .. 198 Key observations from an analysis of the information provided from the SCM2 ...... 199 Evaluation of ‘facilitation’ when using SCOR ............................................................. 203 Summary of the usability criteria to be examined .................................................... 205 Opportunities to automate aspects of the SCM2 ...................................................... 207 Research contribution made by this thesis................................................................ 211 SCM2: Procedure and key concepts for SCM applications ......................................... 214 Summary of issues for future testing ......................................................................... 223 Revisiting Robinson (2006a; 2006b) issues in CM ..................................................... 226 Principle/observations when designing phase one ................................................... 251 Principle/observations made that included the design of phase two ....................... 252 Principle/observations made that influenced the design of phase three ................. 253 Principle/observations made that influenced the design of phase four ................... 254 Principle/observations when designing phase five .................................................... 255 Principle/observations when designing phase six ..................................................... 257 Principle/observations when designing phase seven ................................................ 258 Model components for ‘Retailer plan and place order’ (BeerCo development case) 266 Model components for ‘Wholesaler Receive and fulfil order’ (BeerCo development .................................................................................................................................... 267 AS-IS Scenario in CoffeePot Co validation case for the ‘Customer’ ........................... 271 AS-IS Scenario in CoffeePotCo validation case for the ‘Warehouse’ ......................... 272 AS-IS Scenario in CoffeePotCo validation case for the ‘Factory’ ................................ 273 TO-BE Scenario in CoffeePotCo validation case for the ‘Factory’ .............................. 274 Evaluation of how the SCM2 uses information........................................................... 275 Issues for testing the ‘usability’ of the SCM2 ............................................................. 277
13
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 14
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 15
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 domainknowledge 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
16
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
17
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. 18
Research can be identified on
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.
19
Introduction
• Chapter 1: Introduction to research project
Development • Chapter 2: Research issues in simulation conceptual modelling for SCM of research applications aim, objectives • Chapter 3: Research programme for and developing, refining and preliminary programme validating the SCM2
Research programme implementation
Conclusion
Figure 1.1
• Chapter 4: Stage I: Review of existing simulation conceptual modelling practice • Chapter 5: Stage II: Forming the specification for the SCM 2 • 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
• Chapter 9: Conclusions and future implications of the research
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.
20
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 21
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
22
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 nonsoftware specific description of the simulation model to be developed, in the context of SCM applications’ 23
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. 24
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.
25
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
26
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 27
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.
28
Table 2.1 Academic literature database
ABI/Inform Global Proquest EBSCO (Business Source Complete) Emerald Science Direct Informs online2
2.2
Selection of contributions that meet search terms in each academic database Search terms Simulation Simulation AND AND “conceptual “conceptual modelling” modelling” AND AND supply operation chain
Simulation AND “Conceptual model” AND Operation
Simulation AND “Conceptual model” AND “Supply chain”
Simulation AND Supply chain
Simulation AND Operation
Simulation AND “conceptual modelling”1
499
226
11
0
1
9
1
408
313
9
2
2
12
1
88
50
7
1
1
2
1
45
56
161
19
1
44
17
727
1,720
72
32
16
131
60
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 2
UK spelling is ‘modelling’ while in US dictionary it is spelt ‘modeling’; accounted for in the search Wintersim and Operational Research Society Simulation Workshop (accessed via www.informs-sim.org)
29
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
30
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 31
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).
32
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) 33
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.
Supply chain simulation approaches
Spreadsheet simulation
System dynamics (SD)
Multi-agent based simulation modelling
Business process DES
Figure 2.1
Discrete-event (DES)
Manufacturing wide DES
Business games
Supply chain wide DES
Enterprise wide DES
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 discreteevent 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.
34
Table 2.2
Classification of simulation approaches
Simulation Approach Spreadsheet simulation
System dynamics (SD) Multi-agent based modelling (MABM) Business process DES Manufacturing wide DES Discreteevent simulation (DES)
Supply chain wide DES
Enterprise wide DES Business games
Use in SCM research Sounderpandian, 1989; Chwif, Barretto, Saliby, 2002; Disney and Towill, (2003a; 2003b) 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 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. Tumay, 1995; Chang and Makatsoris, 2001; Albores, Ball and MacBryde, 2002; Ball, Albores and Macbryde, 2004; Reiner, 2005; Melao and Pidd, 2006. 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. 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. 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. 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
35
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 36
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 37
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, 38
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. 39
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
40
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: 41
‘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). 42
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 43
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
44
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 45
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)
46
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.
47
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 48
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.
49
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
50
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 51
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. 52
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 53
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).
54
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 55
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. 56
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
57
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).
58
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 59
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.
60
Table 3.13
Similarities between an iterative triangulation and grounded theory method Iterative triangulation Similarities with grounded theory process (Lewis, 1997) (Bryman and Bell, 2007) Phase I Groundwork: consists of ground laying steps that define methodological and theoretical The process begins with setting research questions, parameters. Clarifying research questions, theoretical sampling and collecting relevant data. constructs of interest, and case search strategies and selection criteria. The data is coded to generate concepts. There is Phase II Induction: consists of several techniques to movement between earlier steps (iteration), new analyse case data, to track down patterns and data added if required and constant comparison of consistencies and to shape initial conjectures. indicators and concepts to generate categories. The categories are saturated during the coding Phase III Iteration: describes iterative means of process and relationship between categories is refining the emerging theory by creatively explored so that connections between categories generalising beyond the data. emerge. Phase IV Conclusion: concludes the theory development process by evaluating the theory and Further data may be collected to test emerging suggesting future research possibilities. This phase hypotheses which leads to the specification of serves to assess theoretical contributions and to substantive theory. begin bridging theory development with theory testing.
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.
61
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 62
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 63
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.
Methodology Development
Stage I – chapter 4
Review of existing conceptual modelling practice Establish the need for a feasible SCM2
Stage II – chapter 5
Form the specification for the SCM2 Establish the required specification for the SCM2
Stage III – chapter 6
Outline design for the SCM2 Outline design for SCM2
Refinement and preliminary validation
Stage IV – chapter 7
Figure 3.1
Detailed and refined design of the SCM2 Detailed and refined design for SCM2 that meets the specification
Stage V – chapter 8
Preliminary validation of the SCM2 A feasible SCM2
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 64
(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?
65
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.
66
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.
67
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 68
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 69
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. 70
Table 3.24
Design questions and issues to address the requirements
Aim Meet the requirements for an effective model
Requirement Keep the model as simple as possible Build a valid and credible model Procedure
Meet the requirements of good methodologies
Participation Points of entry
Meet the requirements for conceptual modelling of supply chain problems
Supply chain improvements Supply chain objectives Supply chain setting
Typical design questions/issues 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? 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? 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? How are the participants involved in each step of the methodology? How can information be extracted from the participants when necessary? How should the methodology be entered? How should iteration occur within the methodology? How can SCOR be used to describe a supply chain improvement? How can SCOR be used to describe a supply chain objective? 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 71
evaluating the methodology against a set of criteria to demonstrate the SCM 2 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).
72
Table 3.3 5
Criteria for assessing a process framework or methodology
Platts (1993) criteria/ questions posed in Platts et al., (2001) Tan and Platts (2002) subcriteria
Feasibility Could the methodology be followed? Availability of information Timing participation
Usability How easily could the methodology be followed? Clarity Ease of use Appropriateness
Utility Is the methodology worth following? 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. 73
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 74
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 75
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 Case
Summary of cases used to develop and validate the methodology Type
Industry
BeerCo
D
Food and beverage
CarCo
D
Automotive
V
Small kitchen appliances
CoffeePotCo
Background Teaching case used extensively in the simulation literature (e.g. Sterman, 1989; Wilkner et al., 1991; SimchiLevi et al., 2003; Disney et al., 2004) The case represents a detailed and complex supply chain problem of a simplified seat supply chain. FUSION research was funded by ESPRC. Fictionalised case presented in Taylor et al., (2008) of a coffee pot manufacturer.
Sources 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) Collaboration between Aston, Strathclyde and Liverpool in the FUSION research group 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 76
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.
77
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. 78
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.
79
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.
80
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)
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.
Pidd (1999); Morris (1967); Powell (1995a; 1995b); Pritsker (1998); Law and Kelton (2000); Nydick, Liberatore and Chung, (2002) 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)
Distinguish themselves from the above approaches by specifying a Nance (1994); Guru and Savory (2004); Van procedure for detailing a model in terms of its elements, its Frameworks der Zee and van der Vorst (2005); Robinson attributes and its relationships. Examples include the general case (2004a; 2004b; 2008a; 2008b) of systems representation and domain related cases. 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 81
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 82
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.
83
X
X
X
X
X
X
X
X
X
X
X
Brooks (2007)
Chwif, Paul and Barretto (2006)
Chick (2006)
Robinson (2004a; 2004b; 2006; 2008a; 2008b) Thomas and Charpenti (2005)
Pidd (1999) X
Brooks and Tobias (2000)
Robinson (1994)
Innis and Rexstad (1983)
Musselman (1994)
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X X
Use random variables to depict parts of the model
X
X
X
Proper use of data
X
X
X
Using analogies
X
X
X
X
X
X X
Exclude/drop unimportant components in the model
Quantify relationships (connections) between variables Limit the amount of uncertainty in the model/Reduce randomness Assume a well-defined objective function or set of decision criteria/ include only output measures of interest (experimental frame) Split models (divide larger models into smaller components)/ use more than one model
Yin and Zhou (1989)
Zeigler (1976)
X
Ward (1989)
Modelling process: start simple then add complexity and detail Make variables into constants Aggregate variables/group components with certain shared characteristics Restrict/eliminate variables Strengthen assumptions and restrictions
Morris (1967)
Advice on model simplification/method
Type two simplifications
Research contributions on simulation model simplification (advice and methods) Type one simplifications
Table 4.28
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X X
X
X
X
X
X
X X
X
X
X
X
X
X
X
X
X
X
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 84
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 85
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
Musselman, (1994)
Ulgen et al., (1996)
Carson, (2004)
No clearly defined goals and purpose that should be kept in mind for the whole study 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 Involve key decision makers Too much detail in the model Allowing complexity to creep into the model Not defining the ‘real’ problem adequately Too much time spent concentrating on the model building rather than focusing on the problem Ensure that the model is verified and validated (in the context of the computer model) Document the model and supply evidence of any justifications made Not knowing when to stop
Sadowski (1989)
Potential pitfall related to conceptual modelling
Law and McComas (1986)
Source
X
X
X
X
X
X
X
X
X X X
X
X X
X X X
X X X
X X X 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)
86
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) 1) The show-off factor (e.g. incorporating unnecessary detail or features to impress stakeholders) 2) Include all syndrome (e.g. Noninsecurity of models in what technical should be included) 3) Possibility factor (e.g. making use of computer power)
1) Lack of understanding of the real system 2) Inability to model correctly the problem (conceptual model) Technical 3) Inability to translate or code correctly the conceptual model into a computerised model or lack of simulation 4) Unclear simulation objectives
4.3
Consideration of some issues in supply chain simulation Difficulties include too many actors represented in the model, supply chain processes and activities that do not improve the accuracy of the model. The actors, processes to be included in the model and which inputs can be simplified. 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 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. 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. 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 Poorly defined objectives lead to over complex models (Innis and Rexstad, 1983; Yin and Zhou, 1989)
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 87
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 88
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.
89
Table 4.511 Methods used to document CM with examples in the SCM literature Documentation method
Process diagram
flow
Percentage of participants
Purpose
63%
Useful way to understand any business process and show interrelationships between activities in a process (Greasley, 2009)
List of assumptions and simplifications
57%
Logic diagram
31%
Component list
22%
Activity diagram
19%
cycle
UML
14%
Text description
5%
A list of assumptions and/or all simplifications made during the process of creating the conceptual model 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) Lists the components to be included in the model content with some description 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. Language for modelling object systems based on object-orientated modelling methods (Evans and Clark, 1998). Text description of the conceptual model
A diagram or figure which displays the conceptual model graphically Other 8% N/A None 5% N/A *Respondents listed more than one method Source: Extended from Wang and Brooks (2007b) survey of simulation users Visual display
2%
Examples in the SCM literature 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) Bhaskaran, (1998); Petrovic, Roy and Petrovic (1998); Persson and Olhager, (2002); Hwarng et al., (2005) Bhaskaran, (1998); Chan and Chan (2005); Hwarng, et al., (2005) Bhaskaren, (1998); Lee et Changchien and Shen (2002)
al.,
(2002);
Changchien and Shen (2002); Ryan and Heavey (2006); Van der Zee and Van der Vorst (2007)
Alfieri and Brandimarte (1997); Gunasekaran, (1999); Biswas and Narahari (2004) Mason-Jones and Towill (1999); Petrovic (2001); Jammernegg and Reiner (2007); Taylor et al., (2008) Non-identified N/A N/A
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. 90
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 91
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 92
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).
93
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.
94
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.
95
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) A perception, on behalf of the modeller, that the conceptual model Validity will lead to a computer model that is sufficiently accurate for the purpose at hand A perception, on behalf of the clients, that the conceptual model will Credibility lead to a computer model that is sufficiently accurate for the purpose at hand A perception, on behalf of the modeller and the clients that the Utility conceptual model will lead to a computer model that is useful as an aid to decision-making within the specified context A perception, on behalf of the modeller and the clients, that the Feasibility conceptual model can be developed into a computer model Extracted from Robinson (2004b, pg. 67) along with a note of other contributions in support of each
Other notable contributions in support of the requirement Willemain (1994); Kleijnen (1995); Brooks and Tobias (1996); Law (2008) Robinson (2004b); Law (2008)
Willemain (1994) Willemain (1994)
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). 96
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 97
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 98
(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.
99
Table 5.2
Platts (1994) characteristics of successful strategy formulation methodologies
Procedure Well defined stages of: Gathering information; Analysing information; Identifying improvements; Simple tools and techniques; Written record
Participation Individual and group achieve: Enthusiasm; Understanding; Commitment
to
Project management Adequate resourcing, identify: Managing group; Supporting group; Operating group
Point of entry Clearly defined expectations; Understanding and agreement of managing group Commitment from managing and operating groups
Agreed timescale Workshop style to: Agree objectives; Identify problems; Develop improvements; Catalyse involvement; Decision making forum
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
100
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).
101
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
102
Identification of the complexity of a supply problem
Vertical complexity
Spatial complexity Edges connecting the nodes intangible measure of complexity
Levels of supply
supply chain structure
Process links among supply chain partners Types of supply chain partnership
Primary; secondary
X X
X X
X
X
X X
X X
X
X
X
X X
X
X
20
19
18
17
X
16
X
15
12
14
length - number of tiers number of suppliers and customers within each tier number of operating locations or degree of dispersion among members within the system Number of edges connecting nodes level of coupling between firms in the supply network as evidenced in the closeness of working relationship Supply within the firm boundary; supply in a dyadic relationship; supply in a inter-organizational chain; supply in an interorganizational network convergent (assembly); divergent (arborescent); conjoined; general (network) managed business process links; monitored business process links; not managed business process links; nonmember business links
13
Horizontal complexity
Support in the SCM simulation literature 11
Property
1 2 3 4 5 6 7 8 9
Characteristic
Support in the general SCM literature 10
Table 5.3
X X
X
X
X
X
X
X
X
X
X
X
X
Information flows; product X flow Logistics; marketing & sales; Business functions finance; R&D; production; & X X X X purchasing Customer relationship management; customer service management; demand management; Supply chain business order fulfillment; X X X X X X X X X X process types manufacturing flow management; procurement; product development and commercialization; returns 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) supply chain flows
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. 103
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 Property
Identification of the detail of supply chain improvements Sub-properties
Supported in the general SCM literature 1
Level of aggregation Supply network decomposition Process decomposition and detail
Impact of customers’ variability on internal operations; general product and customer categories; interactions with customer Level 0 supply network architecture level 1 strategic processes; level 2 tactical processes element; level 3 operational processes or task; level 4 activities; level 5 actions
2
3
4
5
Support in SCM simulation literature 6
7
8
9
10
11
12
13
14
X
X
X
X
X
X
X
X
X
X
decision making Strategic; tactical; operational X X X X X X X X levels 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.
104
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 105
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 SCM
2
Aim 1
Meet the requirements for an effective conceptual model
2
Meet the requirements of good methodologies
3
Meet the requirements of the requirements for conceptual modelling of supply chain problems
106
Requirement Keep the model as simple as possible; Build valid and credible models Provide a procedure; Note who should participate in each step; Embed points of entry 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
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.
107
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.
108
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.
109
Table 6.1
Proposed stages for conceptual modelling in general suggested in the literature
Shannon (1975)
Conceptual modelling stage
Specification of the model purpose
Author Robinson and Pace (1999; Bhatia (1995) 2000a; 2000b) Collect authoritative Identifying the information on problem the problem domain Set the objectives
Define the experimental factors and reports
Purpose and applicability in the context for SCM applications
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)
Determine the modelling objectives
Define the objectives to evaluate each supply chain improvement
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).
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.
Identify entities and processes that need to be represented
Specification of the model component’s Specification of the parameters and variables associated with the components Specification of the relationships between the components, parameters and variables
Robinson (2004a)
Determine the scope and level of the model
Identify simulation elements Identify relationships between simulation elements
Collect and analyse data Provide a project specification
Not within the scope of conceptual modelling
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 110
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 111
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
112
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.
113
Table 6.2
Incorporating model simplification advice and methods into a methodology
Advice on model simplification/method (From table 4.2) Modelling process: start simple then add complexity and detail
Make variables into constants
Aggregate variables/group components with certain shared characteristics Restrict/eliminate variables Strengthen assumptions and restrictions Exclude/drop unimportant components in the model Use random variables to depict parts of the model
Ideas for incorporation into the methodology 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. 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. 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. Variables can be eliminated if they do not have an effect on model accuracy or simplified with random variables. 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. 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. 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) Split models (divide larger models into smaller components)/ use more than one model Proper use of data
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. 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. 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:
114
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.
115
Table 6.3
Documentation and validation requirements for the SCM
General conceptual modelling stage (Robinson, 2004a; 2004b)
Desired outcomes
Developing an understanding of the problem situation
Description of the problem situation from the clients perspective
Determine the modelling objectives (and how each improvement is to be represented)
Model objectives
Design the conceptual model: inputs and outputs
Experimental factors; Responses
What are the requirements for documenting the desired outcome from each stage in the context of SCM applications? Description of the objective of study Description of how the supply system is to be improved Description of the supply setting Description of how each process is to provide data used to calculate each objective Description of how each process is to represent each improvement List of model processes and source inputs that provide an interconnection
Description of the components that represent each actual practice and how their relationships Design the conceptual model: the model content
Model components; Relationship between components
Description of the actual practices to be modelled and their relationships Description of any assumptions or simplifications incorporated into the model components and interconnections
2
How can it be validated?
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.
Check the description of how the objective is to be measured and how an improvement is to be represented for ‘correctness’ with SME’s. Check with SME’s that the processes and source inputs are correct for the purpose at hand. 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. Check how each model component and their interconnections provide a sufficient and correct link between the objectives and improvements. 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)
116
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
1. Meet the requirements for an effective conceptual model
Requirement Build the most simplest model for the purpose at hand Build a valid and credible model Procedure
2. Meet the requirements of good methodologies
3. Meet the requirements for conceptual modelling for SCM applications
Participation Point of entry Supply chain improvements Supply chain objectives Supply chain setting
Opportunity to make the process more efficient and focused Use domain knowledge to extract an accurate representation of the real system for the purposes at hand Aid in formulating the problem precisely from the client’s perspective and focus consultations with SMEs to determine the model content (Law, 2008) Steps and information requirements can be described using standard terms and language common to the SCM domain Procedure that suggests how the participants should be involved the process and what information is required from them. N/A 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.
117
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 SupplyChain 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 118
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.
119
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).
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.
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.
Systematic design
Not detailed. All that is claimed is that it has been developed and evaluated with industrial collaborators (see note in ‘correctness’).
120
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. 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. 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’. 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).
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
List of supply chain improvements (‘best practices’)
List of objectives and metrics (‘performance attributes and metrics’)
Supply setting (‘Supply processes and their relationship’)
Detail offered by SCOR 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) 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 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).
121
Table 6.7
Examples of two typical supply chain problems Disney and Towill (2003a; 2003b)
Contribution
Reiner and Trcka (2004) Supply chain design: Problems and alternatives for a production company in the food industry: A simulation based analysis
Southhard and Swenseth (2008)
Chang et al., (2007)
On the benefits of CPRFR and VMI: A comparative simulation study
Evaluating VMI in nontraditional environments
A study of an augmented CPFR model for the 3C retail industry
Sari (2008)
Example case in the literature
The effect of vendor management inventory (VMI) dynamics on the bullwhip effect in supply chains
Objective 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 (cycletimes)
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
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
of
Improvements
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
SCOR processes P1, P2, P4, S1.1, S2.1, S3.3, ES.7, D1, D1.5, VMI D1.6, D2.5, D2.6, D3.5, D3.6 P1 (Plan Supply CPFR Chain) Extracted from: SCOR V.9 (2008) Improvement
Impact on supply chain performance attributes/metrics Reliability Costs VMI helps to assure the availability of Inventory level decreases by up to 20% leading to items thereby helping to ensure lower inventory costs. The supplier gets a clear view better on-time delivery performance of demand and flexibility (see above), so that they as well as greater fill rates can achieve lower variable manufacturing costs Better store in stock (2% - 8%) Lower logistics cost (3% - 4%) Better customer service (2% - 8%)
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 122
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 Performance attribute Improve supply chain cost by minimising WIP inventory
Minimise finished goods inventory
Maintain customer service level (fill rate)
Example of extracting SCOR performance measures Performance metric level Level 1 metrics
Level 2 metrics
Level 3 metric
Level 3 metric
Performance metric
Definition of metric calculation
CO.1.1 Total Supply Chain Management Cost CO.3.69 Cost to manage in-process products (WIP)
TSCMC = Cost to Plan + Source + Make + Deliver + Return + Mitigate Supply Chain Risk
Any related level process category
The sum of the costs associated with managing in-process products (WIP)
EM.4 Manage inprocess products (WIP)
Current on hand finished goods inventories including safety stock required to sustain current order fulfillment, assuming optimized inventory practices
EM.4 Manage inprocess products (WIP)
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
AG.3.39 Current Onhand finished goods inventories
RL.3.36 Fill rate
Data collection source 2
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
123
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-toorder 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.
124
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.
125
Table 6.10
Key concepts to be included in the design of the SCM Key Concept
1.
Supply chain problem describe the objective, improvement and supply setting
2.
SCOR SCM performance metrics can be used to identify how an objective is to be measured
3.
SCOR practices can be used to describe each improvement to be evaluated
4.
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 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
5.
6.
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 Modelling practice should represent the complexity and detail of the actual practice to be evaluated
9.
10. The conceptual model documented and validated
is
2
Description 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 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 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 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. The source process element that feeds an input to each process element included in the model are considered for inclusion in the model 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. 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). 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. 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. 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.
126
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 127
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 SCM Key concept
1. 2. 3. 4.
5.
6.
7. 8.
9.
Supply chain problem describe the objective, improvement and supply setting SCOR SCM performance metrics can be used to identify how an objective is to be measured SCOR practices can be used to describe each improvement to be evaluated 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 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 Included process elements are considered in turn to identify those that could be simplified The detail that needs to be included can be identified from the actual practice for each process element included and simplified in the model Modelling practice should represent the essential complexity and detail of the actual practice to be evaluated
10. The conceptual model is document and validated
Conceptual modelling process Problem structuring and setting objectives Defining the experimental factors and reports
2
Phase in SCM2 Phase 1: Describe the supply chain problem from the clients perspective Phase 2: Determine how each objective is to be measured Phase 3: Determine how each improvement is to be represented Phase 4: Determine the model inputs and source process elements that interconnect within the model and the immediate supply setting
Determining the model content (i.e. complexity
Phase 5: Formulate the model boundary
and detail)
Phase 6: Design the level of detail necessary to implement the model
Provide a specification
128
project
Phase 7: Document conceptual model
and
validate
the
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.
129
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 From the client: Supply chain objective(s) Supply chain improvement(s) Supply setting 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 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) 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
Phases in the (SCM)2
Outputs from the (SCM)2
Phase 1: Describe the supply chain problem from the clients perspective
Statement of supply problem
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
Phase 3: Determine how improvement is to be represented
Statement of how each process is to represent each improvement (i.e. list of processes germane to each improvement)
each
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 130
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.
131
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.
132
Phase 2:
Phase 1:
Determine how each objective is to be measured
Describe the supply problem Output: Description of the improvement(s) to be evaluated, for a given objective(s) within its supply setting
Output: Description of the core processes that provide data used to calculate each objective
Point of entry A formal problem formulation and structuring methodology or unstructured problem from client
Phase 6:
Phase 3: Phase 7: Determine how each improvement is to be represented
Document and validate the conceptual model Output: A valid description of the computer model to be developed
Output: Description of the core processes that represent each improvement
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
Phase 4:
Determine how the inputs and their sources interconnect within the model and with its immediate supply setting
Phase 5: Formulate the model boundary Output: List of processes and inputs included in the model
Output: List of inputs and candidate processes for possible inclusion in the model boundary
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 133
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)
134
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 ch aracteristics 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) 135
(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 reallife 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. 136
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.
137
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 138
In relation to how information is used and provided, the outline design argued that using domainknowledge (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 139
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 SCM
2
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 Obtain from the client the desired impact (e.g. minimise, maximise, Describe the objectives of study, in terms of the impact on maintain) on supply chain performance Description of the 1.1 supply chain performance attributes, that the improved attributes. objective(s) of study supply system should achieve Use SCOR descriptions of supply chain performance attributes (SCOR V.9, section 3) as a guide Obtain from the client situational Description of the Describe the alternative [set of] supply chain information. alternative 1.2 improvement(s) in terms of how and which actors are Use SCOR descriptions of practices improvements to be affected by the change (SCOR V.9, section 4) to select and made to the existing describe each improvement system Describe the nature of the setting of the supply problem (e.g. actors in the supply system that have a cause and Obtain from the client information on Description of the supply 1.3 effect relationship between the improvement and the general supply problem setting problem setting objective, and any important situational information) that may influence the scope of the problem 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; State the means by which each improvement is to achieve Use SCOR descriptions of impact of Description of how each each objective, by bringing about change in the supply 1.4 each practice on performance improvement could system (in terms of desired impact on performance attributes, if the improvement is achieve each objective attributes) 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 Check that the description provided from steps 1.1 – 4 are Consult with the client on each Description of the supply 1.5 ‘correct’ from the perspective of the client making any description (Information provided from problem from the client’s alterations as deemed necessary before proceeding 1.1 – 4) 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.
140
Table 7.2
Description of the objective(s) of study
Description of the objective(s) of study
From step 1.1
1. 2.
BeerCO development case Minimise total supply chain costs (-) Maintain customer service (-)
CarCO development case 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.
141
Table 7.3
Description of the alternative improvements to the existing system
Illustration of the description of the improvements selected
From step 1.2
BeerCO 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. The information is used by the distributor to plan deliveries and how orders are placed with the factory.
CarCO development case 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.
142
Table 7.4
Description of the supply problem setting
Illustration of the description of the supply problem setting
From step 1.3
BeerCO case 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
CarCO case 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 Description of how each improvement could achieve each objective
Illustration of how each improvement could achieve each objective
From step 1.4
BeerCO case 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.
CarCO case 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 143
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 144
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.
145
2
Table 7.6 Detailed steps for phase two of the SCM Phase two: Determine how each objective will be measured Process steps Information required Point of entry: From phase 1: Description of the objective(s) of study (information provided from step 1.1) Use SCOR level 1 strategic metrics (SCOR v.9, section 2) to decompose each supply 2.1.1 Specify the high level chain performance attribute. strategic level 1 metrics Objective(s) of study (from associated with each 1.1). performance attribute How each objective is to achieve each improvement (from 1.4) Specify the supply chain Use SCOR level two diagnostic performance measures for each 2.1.2 Specify (if any) the level metrics (SCOR v.9, section 2) 2.1 objective, in the context of how two metric(s) that provide the to decompose each level 1 each objective is to achieve each lower level calculations for each metric if necessary. improvement higher level strategic level one How each objective is to metric achieve each improvement (from 1.4) Use SCOR level three diagnostic metrics (SCOR v.9, 2.1.3 Specify (if any) the even section 2) to decompose each lower level three diagnostic level two metric if necessary. metric(s) for each higher level How each objective is to metric achieve each improvement (from 1.4) Use SCOR metric calculation 2.2.1 Define the calculation for descriptions for each metric Define how each performance each metric (SCOR v.9, section 2) metric will be calculated from the 2.2 data sources that are used to 2.2.2 Specify the processes that Use SCOR data collection drive the calculation generates each data source for descriptions for each metric each metric (SCOR v.9, section 2) 2.3.1 Specify the actors associated with each data source Derive from the supply Define the nature of the process problem statement (from 2.3 measurement for each supply phase 1) and class of 2.3.1 Specify the measurement chain performance metric measures (from 2.1) span for each performance metric Check the outputs from 2.1 – Check that the outputs provided from steps 2.1 – 2.3 correctly 2.3 with the objective 2.4 interpret the objective(s); make any alterations as necessary before described in 1.1, if necessary exiting phase two confirm with the client Point of exit: To phase 3: Proceed only when the description of how each objective that will be measured is agreed as ‘correct’
Information provided
Hierarchy of supply chain metrics to measure each objective
List of calculations and data source requirements for each metric
Definition of nature measurement each metric
the of for
Description of how each objective will be measured
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 146
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 stockouts 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
Hierarchy of supply chain metrics to measure each objective
From step 2.1
1. 2. 3.
R.L.2.1 % of orders delivered in full CO.1.1 Total supply chain management cost AM.2.8 Inventory: Capital employed in finished goods stock
147
CarCo development case R.L.3.20 % orders received on-time to demand requirement
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. 148
Table 7.8
Description of calculation and data source requirements for each metric 1.
List of calculations and data source requirements for each metric
From step 2.2
2. 3.
BeerCo development case [Total number of orders delivered on the original commitment date]/[total number of orders delivered] X 100% Sum of finished goods inventory stock cost at each actor location The amount of finished goods inventory (stock) on hand to support customer service, expressed in dollars
CarCo development case
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 1.
Description of the nature measurement for each metric
of
From step 2.3
2. 3.
BeerCo case D1.3, D1.12, D1.13 (wholesaler process) D1.8 (all actors – supply chain) D1.8 (Factory, distributor, wholesaler, retailer – process)
CarCo case 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 149
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.1 Specify the level 1 top level (process types) Use SCOR v9.0 best practice guide described in that define the scope and section 4 to identify process types associated with content each improvement identified in phase one. If no 3.1.2 Specify the level 2 practices can be identified for each improvement configuration (process List of processes at Define the level of then the processes must be selected that are categories) to implement three levels of process process detail for critical to represent each improvement (verified 3.1 an organisation detail that represent each supply chain with client sources). operations strategy each supply chain improvement option Consult the client on how each improvement will improvement option 3.1.3 Specify the level 3 affect the supply system – the effect of each process elements improvement (on processes in the supply system) (decomposed processes) also needs to be included in the description of the that “fine tunes” an improvement organisations operations strategy List of actors Specify the actor(s) associated with implementing Derive from phase one statement of the supply 3.2 associated with each each business process problem, verified with the client if necessary business process Check that the outputs provided from steps 3.1 – Check the outputs from 3.1 – 3.2 with the Description of how 3.3 3.2 correctly interpret the improvement(s); make improvement(s) described in 1.2; if necessary each objective will be any alterations if necessary before proceeding confirm with the client 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 150
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) 151
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 1.
List of processes at three levels of process detail that represent each supply chain improvement option
2.
Level 3 (process element): D1.2 (Receive, enter and validate orders); D1.3 (Reserve inventory & determine delivery date) Level 2 (process category): P2: (plan source); P4 (plan deliver)
1.
2.
Level 2 (process categories): P2 (plan source); P4 (Plan deliver) 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 1.
List of actors associated with each business process
2.
Implemented at the wholesaler Implemented at the distributor
CarCo case 1.
2.
P2 implemented at the Luxury automotive manufacturer; P4 implemented at both the central-headrest and tracks tier 3 suppliers 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 152
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 153
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 SCM
2
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 From phase two and three for 4.1.1 List all the process elements core process elements. included in the model Phase five for promoted process elements. Use SCOR (SCOR, v.9 section 3): 4.1.2 Add the inputs to be fed to each Processes to identify the input process element included in the model descriptions for each process List of inputs to each element List the inputs fed process element included in to each process 4.1.3 Add the source process element 4.1 the model, their source element included that generates each input to be fed to process elements, specified in the model a process element included in the As above by actor model, consolidating the list where possible As above, but specify the actor 4.1.4 Specify the actor that generates using the description of the supply the input from the source process problem as a guide (from step 1.4 element - verify with the client if necessary) List of model inputs and Discriminate the source process elements that generate each Verify using output from step 2.4 candidate process elements 4.2 input to be fed from a process element included in the and 3.3 for possible inclusion in the model 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)
154
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
155
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).
156
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.
157
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.
158
Table 7.14
Detailed steps for phase 5 of the SCM
2
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. Use the list of candidate List of inputs fed process elements from 4.2.1 List all the inputs generated and fed by each candidate process from each candidate 5.1 and 4.2.2, list of inputs from element, specified by each actor (if necessary) process element (for 4.1.1, Derive actors from 2.2 each actor) and 3.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) 5.2.2 PROMOTE candidate process element that generate inputs that will effect model behaviour by significantly impacting on the performance measures Determine whether to List of SIMPLIFIED, AND CANNOT be simplified in a simplified simplify, promote, test Use the SCOR input PROMOTED, form (either a fixed value or distribution) or exclude each descriptions (SCOR v.9, section TO TEST or 5.2 5.2.3 TEST candidate process elements if a candidate process 3) and verify with the client if EXCLUDED process decision cannot be made about whether element by applying rule necessary elements/inputs the input to be generated will have an 1 and 2 with justification 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 If any process elements were PROMOTED then go to If any process elements were PROMOTED in step 5.2.2 then repeat phase four and steps 5.1 – 3; 5.3 phase four and five until no process elements can be included in the When no process elements can no longer be model and inputs to be fed can be SIMPLIFIED. PROMOTED then proceed to step 5.4. Use Information from step 1.5 5.5.1 In a table list each actor and note and 2.4 (core process which CORE and PROMOTED process elements); step 5.2 (promoted elements and SIMPLIFIED input are process elements and included in the model simplified inputs) 5.5.2 For each improvement that could achieve each objective. Trace the inputs Use information provided from processes that provide data sources from step 1.4 (description of Check that there are to drive the calculation for each objective how each improvement could sufficient and correct to the point that a sufficient and correct achieve each objective); 5.2 List of processes and linkages between link is made with the processes that (interconnections between inputs included in processes and inputs represent an improvement. Use the table 5.4 processes and inputs) included in the model the model specified to tick off each process that provides a and that there are no by actor link. isolated process 5.5.3 Any remaining ‘isolated’ processes elements in the model and simplified inputs should be checked using the justifications provided to verify step 5.3 (justification for each that they are necessary as they effect decision) model behaviour by having a significant impact upon the objectives of study 5.5.4 If any isolated process elements or inputs exist that cannot be justified then Use information from 5.5.3 return to step 5.2. 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
159
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).
160
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 “infull” 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 161
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. 162
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.
163
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.
164
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.
165
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 designorientated 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.
166
Table 7.15
Detailed steps for phase 6 of the SCM
2
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.1 List the process elements List of process elements Use the list presented in within the boundary of the specified by status for phase five model, by status and actor each actor 6.1.2 Identify ‘phantom’ process elements by determining the Use the list from phase five process elements that contain to identify the inputs to List of process elements that are to be treated as Describe how each process only a workflow input and no each process element; element is actually practices can be identified that Verify if necessary with the ‘phantoms’ influence the client implemented in practice, in would sufficient detail of how the characteristics of the workflow 6.1 inputs (and sources) are Use SCOR v.9 process converted to produce an element descriptions (SCOR 6.1.3 Describe actual practice for List of descriptions of output (to a destination), v.9, section 3) to identify the existing ‘AS-IS’ and ‘TO-BE’ actual practice for each specified by each actor practices from the list of supply system for ‘core’ and included ‘AS-IS’ and ‘TOcandidates, as a guide to aid ‘promoted’ process elements BE’ process element in the collection of information from the client 6.1.4 Consolidate the list of Consolidated list of actual practices, removing any Use the list from 6.1.3 actual practices duplications 6.2.1 Describe what processes, Description of the activities or events need to be Use descriptions processes, activities or included in the computer model consolidated in 6.1.4. events to be included in to represent each actual practice the computer model 6.2.2 Describe what entities Description of the Describe how each actual need to be included to represent Use the descriptions from entities to be included in practice, specified by each the activities or events in the 6.2.1 the computer model 6.2 actor, will be represented by computer model? the components in the 6.2.3 Describe any assumptions Description of any computer model or simplifications incorporated assumptions or into the description of the simplifications Refinement of 6.2.1 and model to be developed (e.g. incorporated into the 6.2.2. aggregation of model description of the components, reduce the rule components in the set) 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. 167
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 168
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. 169
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.
170
Table 7.16
Model components, definitions and examples (in the BeerCo development case)
Questions asked in step 6.2
Model Components Process
What activities or events need to be implemented in the model to represent the actual practice?
Activity
Event
Entity How will the activities/events be represented in the model? Resources
Definition
BeerCo case examples
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
An operation over a duration of time of finite length that causes change in the system state (Tanir and Sevinc, 1994). 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). Individual elements of the system that are being simulated and whose behaviour is being explicitly tracked (Pidd, 2004a; 2004b) 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)
Receive product
product,
ship
Product arrives at warehouse, customer place order, initiate sourcing plan cycle Warehouse, orders, vehicle, delivery schedule Number of units of beer available in warehouse, number of units of beer on vehicle
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)’ 171
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 172
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)
173
Table 7.17
Detailed steps for phase 7 of the SCM
2
Phase 7: Validate and document the conceptual model Information required
Process steps
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.1 Draft a description of the supply problem from the client’s From phase perspective 1 7.1.2 Draft a description of how each process is to provide data From phase used to calculate each objective 2 A draft nonDraft the conceptual 7.1.3 Draft a description of how the processes represent each From phase software specific model by describing improvement 3 description of 7.1 the computer model to 7.1.4 Draft a description of how the components and their the simulation From phase be developed model to be relationships in the computer model will represent each actual 6 developed practice to be modelled 7.1.5 Draft a description of the assumptions and simplifications From phase that have been incorporated into the model components and 6 relationships 7.2.1 Check the description provided from step 7.1.1 by repeating From 7.1.1 step 1.5; If not correct return to the beginning of phase 1. 7.2.2 Check the description provided from step 7.1.2 by repeating From 7.1.2 step 2.4; if not correct return to the beginning of phase 2 7.2.3 Check the description provided in 7.1.3 by repeating step 2.4; From 7.1.3 if not correct return to the beginning of phase 3 From 7.1.4; Description 7.2.4 Check the correctness of the descriptions provided in step of how each 7.1.4 by asking SMEs the following question (e.g. circulate the improvement draft description for feedback and/or provide a structured is to achieve walkthrough of the actual practices and relationships in the each Validate the model): Does the description of the actual practices and objective ‘correctness’ of the relationships in the model provide all the necessary details to be described in draft descriptions of List of issues that sufficiently accurate to evaluate the means by which each 1.4; the simulation model need to be improvement is to achieve each objective. if not correct return to Consult to be developed. If any resolved by the beginning of step 6.1 SMEs on 7.2 issues arise then returning to a each revision and previous phase description adjustments are or step (only if 7.2.5a Check the correctness of the descriptions provided in step required by returning necessary) 7.1.4 by examining each of the connections between model to a previous phase or components, to determine whether the conceptual model From 7.1.4 step. reproduces the actual practices and relationships? If not correct then return to step 6.2 7.2.5b If necessary, to support the analysis in 7.2.4: Represent the components and relationships using a graphical means of See above representation (e.g. process flow diagram, logic flow diagram, activity cycle diagram). 7.2.6 Check the draft description of each of the assumptions and simplification that have been incorporated into the model From 7.1.4; components and interconnections described in 7.1.4 with the Consult client for the level of confidence that can be placed in them and SMEs their likely impact on the accuracy of the model; If not correct then return to step 6.2.3 A final nonsoftware specific From 7.1 and description of 7.3 Document the final non-specific description of the simulation model to be developed 7.2 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 174
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 175
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.
176
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. 177
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. 2
Table 7.18
Aligning the SCM to meet the requirements for an ‘effective’ model Realised in the SCM2
Requirement
Keep the model as simple as possible
Build
valid
credible models
and
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 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. 178
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.
179
Table 7.19
Meet the requirements of ‘good’ methodologies Realised in the SCM2
Requirement
Provide
a
procedure
Meet
the
requirements of good methodologies
Participation in each step
Embed of entry
points
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 between the modeller, the client and SMEs (see building a valid and credible conceptual model) 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. 180
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 Realised in the SCM2
Requirement
Handle
supply
chain
improvements
Address a range of supply chain objectives
Identify interconnections within the supply setting
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. 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) 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:
181
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 SCM 2 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 domain182
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.
183
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 184
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
8.2
Graphical illustration of CoffeePotCo supply problem
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 185
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 objective(s) of study
Output from 1.1
Description of improvements to change the existing system
Output from 1.2
Description of problem setting
Output from 1.3
the
Statement of how each improvement could achieve the desired impact on the objective(s)
Output from 1.4
Statement of supply chain problem 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). 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. 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. 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 reorder 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 186
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 highincome/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.
187
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
Output from 2.1
Definition of metric calculation
Process elements
Output from 2.2
Assets
Level 3 metric
AM3.16: Inventory days of supply
(Value of finished goods inventory/(COGS/365))
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%
Actor
M’ment span
Output from 2.3 S1.4
WH
Process
D1.8
WH
Process
D1.3 D1.12
WH WH
Process 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 188
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 Level of Improvement option process detail Output from step 1.1.2
Business process
Output from step 3.1
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.
Actor Output from 3.2
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 189
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 190
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 191
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
Customer
N/A
Simplified inputs (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.
192
Table 8.5 Candidate process elements promoted in each round (CoffeePotCo) Number of iterations between phase five and six Initiated with core process elements Iterative round 1 Iterative round 2 Iterative round 3 Iterative round 4 Iterative round 5 Iterative round 6
Candidates process elements promoted in step 5.2.2 Factory Warehouse S1.4, D1.8, D1.3, D1.12, D2.10, D2.11, D2.12, D2.13 D1.13 S1.2, S1.3, S1.1, P4, P2, D2.9 D1.2, D1.11 M2.1, M2.6, D2.7, D2.8 D1.5, ED.4 P3, M2.3, M2.4, M2.5, D2.6 D1.4, D1.10 D2.3, P4 D1.9 D2.3, D2.5, D2.4 D1.7 D2.2 D1.6
Customer N/A None identified (S1.1 – simplified)
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.
193
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 194
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 subcriterion 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
Can the methodology be followed to describe the actual practices to be included in the model?
Sub-criteria (Tan and Platts, 2002) Availability of information – whether sufficient details were provided at each step in order to complete them successfully (Blackwell, 2003)
195
Question addressed in this thesis Was there sufficient information required and provided by the steps to complete them successfully?
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) Relevance – No definition available
Does the methodology aid a user to describe a useful and relevant set of actual practices to be included in the computer model?
8.4
Usefulness – Blackwell (2003) described this as whether the worksheets and tools included in the methodology helped the would-be user to progress through it. 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
Question addressed in this thesis Is the outcome from the methodology (description of the actual practices to be represented in the computer model) applicable for the purpose at hand? 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)? Did any problems arise when using the methodology? Any areas that need to be addressed in further work?
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.
196
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.
197
Table 8.8
Key observations from an analysis of the information requirements for the SCM
Information required by the methodology Clarity of terms and means of communication
Describing the objectives
Describing the improvements
Describing the inputs and interconnections in the model
Deciding what to include in the model Identifying and describing actual practice
2
Key observations 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 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. 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. 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. 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. 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 198
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 SCM
2
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 Decomposed business processes necessary to represent each improvement for each actor List of process elements and inputs and decision on their boundary status List of process elements that have been treated as ‘phantoms’
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 As above Improves decision-making and documentation of decisions made 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 199
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. 200
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. 201
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
202
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 Descriptions offered by SCOR SCOR practices
SCOR metrics
SCOR decomposed business process descriptions
Evaluation of ‘facilitation’ when using SCOR Observation in CarCo case Practice not adequately covered No issues identified No issue identified
Comment 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 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 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
203
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 204
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) Clarity – Blackwell (2003) defined this as how well the methodology was structured
How easily can the methodology be followed?
Ease of use – Blackwell (2003) defined this as how easy the methodology was to be used and understood Appropriateness – Blackwell (2003) defined this as the length of the methodology and how it might be either extended or reduced
Question addressed in this thesis Are the steps in the methodology clear and well structured in order for a potential user to achieve the desired outcomes? Can the methodology be followed with ease and be understood by a potential user? 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 205
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.
206
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 SCM
2
Automation concept
Description
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
Identification of interconnections between processes
Discrimination of candidate process elements
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) 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.
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
Automate the phantom process rule
Processes that meet the ‘phantom’ criteria can be automated making the step redundant in phase six
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.
Link to key concept described in the design 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)
Key concept 4: see above
Key concept 5: Process elements that have yet to be included in the model can be classed as candidates for possible inclusion 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 Key concept 7: Included process elements are considered in turn to identify those that could be simplified 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 207
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. 208
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.
209
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.
210
Table 9.113 Research contribution made by this thesis Research contribution made by this thesis Primary research contributions:
1.
2.
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)
Preliminary validation of a methodology for creating simulation conceptual models for SCM applications (summarised in section 9.1.1.2)
Gap addressed in existing research 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). 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.
Research Obj./Q’s
Thesis ref.
Obj. 2; Q3
Chapter 6 and 7
Obj. 3; Q4
Ch. 8
Obj. 1; Q1
Chapter 4
Obj. 1 Q1
Chapter 5
Secondary research contributions:
3.
4.
Examination of existing simulation conceptual modelling practice in SCM (summarised in section 9.1.2.1)
Specification of the requirements for simulation conceptual modelling in SCM (summarised in section 9.1.2.2)
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. 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.
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 211
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)
212
Aid in providing clear domain-specific guidelines for extracting information from a predefined 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 domainspecific 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. 213
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. 2
Table 9.214 SCM : Procedure and key concepts for SCM applications Procedure Key concepts for SCM applications Phase one: Describe the supply problem - The supply 1. Supply chain problem: describe the problem is described from the perspective of the client objective, improvement and supply setting Phase two: Determine how each objective is to be 2. SCOR SCM performance metrics can be used measured – The objective is described in terms of how to identify how an objective is to be it will be measured measured Phase three: Determine how each improvement is to 3. SCOR practices can be used to describe each be represented – The improvement is described in improvement to be evaluated terms of how it is to be represented 4. Identification of the core processes that Phase four: Determine how the inputs and their need to be modelled, their inputs generated sources interconnect within the model and with its from a source process element immediate supply setting - Provide a list of model 5. Process elements that have yet to be inputs and candidate process elements (NB: supplies included in the model can be classed as information only to formulate the model boundary) 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 Phase five: Formulate the model boundary – Provide core processes and the real world a list of processes and inputs included in the model 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 Phase six: Design the level of detail to implement identified from the actual practice for each each process and input included in the model process element included and simplified in boundary – Provide a description of how the actual the model practices are represented by the model components 9. Modelling practice should represent the and relationships between them 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 10. The conceptual model is documented and phases and steps in the methodology are documented validated and validated
214
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).
215
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.
216
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 217
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: 218
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 219
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? 220
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 221
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 222
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 Need to use different facilitators and participants Yes, does SCOR enable a more efficient and focused process? Yes, different participants required Yes, how different participants make use of information
Issue for future testing
Related test criteria
Need to apply in different contexts
How different facilitators utilise the domain knowledge provided by SCOR
Feasibility
-
Feasibility
Yes, different contexts required
Feasibility
Yes, different contexts required
Utility
Yes, can the procedure be repeated?
-
Utility
Yes, Is the output provided from the SCM2 more complete and accurate?
Yes, from a users perspective
Utility
Yes, what issue arises in different contexts?
Yes, from a users perspective
Usability
-
Usability
-
Usability
Yes, identify opportunities to improve the facilitation of the methodology (C.f. section 8.6.3)
Test how different participants are involved in each step Test how the information provided to draft a conceptual model is used at the final validation phase Relevance of the methodology to create a conceptual model that is more valid and credible The usefulness of following a structured approach as opposed to no formal methods Identify from the participants whether any problems arose or need to be addressed when using the methodology The methodology is clear as it is well structured and detailed The methodology should be used by both experts and benefit novice users The methodology is appropriate but can be improved to reduce time consuming activities
223
Yes, from a users perspective Yes, test with experts and novice users -
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. 224
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 SCM 2. 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.
225
Table 9.416 Revisiting Robinson (2006a; 2006b) issues in CM Issue in conceptual modelling (Robinson, 2006)
Advance made in this thesis
Developing consensus over the definition of a conceptual model/conceptual modelling
Yes, in SCM context
Identifying the requirements for a conceptual model
Yes, in SCM context
Development of methods for designing conceptual models including modelling principles, methods of simplification and modelling frameworks
Key concepts and process in SCM context
Moving towards standard methods for representing and communicating a conceptual model
Yes, spreadsheet application proposed (using automation)
Developing procedures for validation of a conceptual model
Yes, embedded in SCM2. The discussions of applicable methods are made in general.
Investigating effective means for teaching the art of conceptual modelling
Development of a methodology that synthesises existing approaches to conceptual modelling
Opportunity for further work 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. 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) 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. 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. 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. 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.
226
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.
227
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).
228
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.
229
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. 817831. 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. 13871394. 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. 230
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. 1318. 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. 231
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.
232
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.
233
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 intraorganisational 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. 234
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 supplychain 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 agentbased 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. 235
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 discretecontinuous 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.
236
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. 10971114. HILL, T. J. (1987) Teaching and research directions in production/operations management: The manufacturing sector. International Journal of Operations & Production Management, 7(4), pp. 512. 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. 2031. 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 237
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. 238
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 processoriented 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. 239
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. 197203 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
240
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. 241
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. 242
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. 811 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. th
PIDD, M. (2004a) Computer simulation in management science, 5 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 multiattribute 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, 4647, 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. 243
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. 244
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. 245
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. 246
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. 170188. 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.
247
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 discreteevent 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. IntegratedManufacturing, 4(4), pp. 197-208.
International
Journal
of
Computer
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.valuechain.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.
248
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 249
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.
250
Appendix A SCM2 Table A.1
Principles/observations made in the design of the
Principle/observations when designing phase one
Principle/observation noted by Robinson (2004, pg. 78 – 81) 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
Accuracy of the description provided by the clients may be dubious
Clients may lack a good understanding of the cause and effect relationships within problem
Client may have a different perspective on the problem
Role of the modeller is to learn from the clients about the problem Description of the problem, in particular the objectives can be used as a means for validating the conceptual model Clients who have a poor grasp of the problem will benefit from more formal problem structuring methods to be used The objectives should be expressed in terms of the level of performance required (also Beamon, 1998) The client may find it difficult to express the set of objectives Understanding can change during a simulation project, so can the objectives. This will impact on the design of the model
Remarks from application
Influence on the design
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)
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 ‘correctness’ (in step 1.5)
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 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. The modeller needs to draft a description of supply problem and check that it is correct with the client The information provided in subsequent phases to describe the conceptual model can be validated against the supply problem (purpose at hand) The client may find it useful prior to entering the first phase of the methodology to use a formal problem structuring method Expressed in terms of desired impact upon supply chain performance attributes (e.g. increase, decrease, maintain) Useful to force the modeller to consider how each improvement is to achieve the desired objective. SCOR can provide information to support this Ensure that the participants agree amongst themselves that the supply problem is described correctly, and return at the end of the process.
251
for
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) 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) Provide a text description of the supply problem (in step 1.4) Incorporated into later phases and a final validation at the end of the process (see phase 7) Include as an approach that could be used prior to conceptual modelling (point of entry) Include in the description of the objectives of study (in step 1.2) The means by which the improvement is to achieve the desired objective is included as a step (in step 1.4) The phase is not exited until the checks have been satisfied and it is reentered if the final validation check identified any issues to be resolved (in step 1.5 and in considered in phase 7)
Table A.2
Principle/observations made that included the design of phase two
Principle/observation
Remarks from application
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
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
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.
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
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
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.
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.
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
252
Influence on the design Phase cannot be entered unless the supply problem has been checked for correctness (point of entry) Decompose the impact on supply performance attributes into specific performance metrics (in step 2.1) 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) SCOR is used to identify and describe supply chain performance metrics at three levels of detail (in step 2.1) Define the calculation and data sources for each metric (in step 2.2) Define the nature of the measurement for each metric (in step 2.2) Include a check and state that the phase cannot be exited until the check has been satisfied (in step 2.4) Treat these processes as ‘core’ – to initiate the model formulation process (purpose of phase 2)
Table A.3
Principle/observations made that influenced the design of phase three
Principle/observation 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. 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) How each improvement is to represented can be described using standard SCOR terminology 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 SCOR describes the ‘causes’ of an improvement but not necessarily suggest the ‘effect’ relationship
Actor associated with implementing each business process needs to be defined
How each process elements is to be represented needs to be checked for correctness
The processes germane to a particular improvement are critical components that need to be included in the model
Remarks from application Difficult to describe the improvement if it has not been described previously. An improvement can be selected from the SCOR practice or can be used as a guide to describe a specific improvement As above, SCOR describes each practice and provides information on the processes germane to implementing them Improvements could be selected from SCOR and adapted to the situation (e.g. actors who implement practice) 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 SCOR does not indicate the actors that would implement a practice, it is situational to the supply problem An incorrect representation of the improvement will lead to the wrong processes being described which initiate the analysis of the model boundary Treat these processes as ‘core’ – to initiate the model formulation process
253
Influence on the design 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). The boundary of the model is formulated initially from the core process elements (purpose of phase 3). Structure the representation of the improvement using SCOR terminology and descriptions (in step 3.1) 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)
The effect of an improvement must also be described (in step 3.1), specified by actor (in step 3.2)
Actors are associated with business process (in step 3.2)
each
Check is implemented at the end of the phase; if it is not completed satisfactory the phase is repeated (in step 3.3) 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)
Table A.4
Principle/observations made that influenced the design of phase four
Principle/observation The core process elements need to be described and checked for ‘correctness’ prior to identifying candidate process elements. 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 included process elements can be listed with their associated inputs and the process element that provides the source.
Remarks from application 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. 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. 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.
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
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’
Considerable number of typo’s that questioned the reliability of SCOR v.9
Treating each entry separately but common inputs, source process elements for each actor could be consolidated 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.
Experimenting with the way in which the question to discriminate between source process elements is asked
Experimenting with how information should be presented to distinguish between entries The phase is complete when all source process elements have been discriminated. It should be completed in rounds for consistency.
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. 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. 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. 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. 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 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.
254
Influence on the design Check implemented in previous phase before proceeding (point of entry) Iteration between steps in phase four and five (Point of entry and exit) List the process elements with their inputs and source process elements that generate the input (in step 4.1) Creation of a template with the data necessary to be extracted. Data is checked with earlier versions of SCOR (in step 4.1) 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). Cross reference SCOR v.9 with v.8 and correct any errors in the template (in step 4.1) Common inputs from source process elements could be consolidated so that they are only considered once (step 4.1) Use the template for the information as defined by SCOR. Consider an opportunity to automate the process in further work (in step 4.1).
Discriminate between each entry for each interconnection in list (in step 4.2)
Use only a ‘yes’ or ‘no’ response when discriminating interconnections (in step 4.2) Complete in rounds and be clear on the points of exit (point of exit)
Table A.5
Principle/observations when designing phase five Principle/observation
The phase is entered in successive rounds when candidate process elements have been described in phase four 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. Each decision includes a combination of the input, generated and fed by each candidate process element specified by actor ‘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 scope of the model must be sufficient to provide a link between the experimental factors and the responses’ (Robinson, 2004 pg. 84) 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 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.
If the participants are unsure about a combination (input, candidate process and actor) then this can be tested using a prototyping method.
Remarks from application 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. 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. The inputs need to considered in terms of the process that generates it and the actor
Influence on the design Enter in successive rounds when data is generated (point of entry) Information is provided from phase four using a common format (in step 5.1) List information in a common format that show input, process and actor (in step 5.1)
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)
There must be a link between the core process elements in the model.
As above
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. 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. 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).
255
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). 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). Use a prototyping method when it is difficult to make a decision about the need to include a particular combination (in step 5.2)
Principle/observation 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. 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. 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. 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. 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. 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. 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. 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.
Remarks from application 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. 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. 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.
Influence on the design
Client is consulted when a decision cannot be made with the information available (in step 5.2)
Document a justification for each decision as a way of forcing the modeller to think through actions (in step 5.2) Document any decisions made (in step 5.2)
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)
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)
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)
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)
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)
256
Table A.6
Principle/observations when designing phase six Principle/observation
Remarks from application
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 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.
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.
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.
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
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.
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
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
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.
257
Influence on the design The phase cannot be entered without the check being completed (point of entry)
Make it clear in the steps that the actor and relationships between practices need to be described (in step 6.1) Use information from phase five on the inputs and outputs for each process (those included) (in step 6.1) Include a sub-step to identify ‘phantoms’ (in step 6.1) Include a sub-step to describe both AS-IS and TO-BE practice (in step 6.1) Include a sub-step for consolidating practices (in step 6.1) Identify the model components in generic terms (in step 6.2) Include a sub-step to identify ways in which to incorporate simplifications and assumptions into the model component descriptions (in step 6.2) When all model components have been described. Validation occurs in the final step (point of exit)
Table A.7
Principle/observations when designing phase seven Principle/observation
Remarks from application
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
Information is provided from the phases/steps that provide descriptions to create the conceptual model
Relatively straightforward and completed with ease
It is necessary to validate the final model in case any new insights or learning has been identified during the process. Previous checks can be redone; if any issues are identified then the user must return to that phase/step
During early refinements models were thrown away due to new learning about the system
Influence on the design From phase six when the model components, their relationships and the assumptions and simplifications incorporated into the model are described (point of entry). Obtain descriptions from previous phases/steps (in step 7.1) Validate the descriptions by performing previous checks (in step 7.2)
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 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.
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).
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
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
258
Include an hypothesis test (in step 7.2)
Be clear which steps are applicable to the different participants (in step 7.2).
Include an option if necessary to represent the conceptual model using a graphical means (in step 7.2). Be clear which steps are applicable to the different participants (in step 7.2).
Principle/observation 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) 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) The final conceptual model is one which has been validated
Remarks from application
Influence on the design
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).
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).
Final model can be presented when it has been validated
Include a final documentation step (in step 7.3)
259
Appendix B Actual practice to be modelled (BeerCO development case) Boundary setting status
Process element
Actor location
CORE
P2
Distributor
PROMOTED
P2
Wholesaler
PROMOTED
P2
Retailer
CORE
P4
Distributor
PROMOTED
P4
Wholesaler
PROMOTED
P4
Factory
PROMOTED
S1.1
Distributor
PROMOTED
S1.1
Wholesaler
PROMOTED
S1.1
Retailer
SIMPLIFIED
S1.1
External customer
PROMOTED
S1.2
Distributor
PROMOTED
S1.2
Wholesaler
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 TO-BE description for each process process Allow a human player to calculate the The distributor calculates the planned order quantity for the distributor planned order quantity based on role based on a rule. This rule should be a rule (e.g. The wholesalers order experimented with to demonstrate how the = distributors purchase order. visibility of the wholesaler current order, The distributor places an order finished goods stock levels and incoming raw that is as large as the wholesaler materials (crates of beer) influence the order). decision. The wholesaler calculates the planned order quantity based on a rule (e.g. The retailers order = No change wholesaler purchase order. The wholesaler places an order that is as large as the retailers order) The retailer calculates the planned order quantity based on a rule (e.g. The external customer order = retailers purchase order. No change The retailer places an order that is as large as the customer’s order) The distributor calculates how Allow a human player to calculate the much beer to deliver to the planned delivery quantity for the distributor wholesaler based upon rule (e.g. role based on a rule. This rule should be Distributor deliver to actual experimented with to demonstrate how the wholesaler order to the extent visibility of the wholesaler current order, possible from the distributor finished goods stock levels and incoming raw available finished goods materials (crates of beer) influence the inventory) decision. The wholesaler calculates how much beer to deliver to the retailer based upon rule (e.g. Wholesaler deliver to actual No change retailer order to the extent possible from available finished goods inventory) The factory calculates how much beer to deliver to the distributor based upon rule (e.g. factory deliver to actual distributor order No change to the extent possible from available finished goods inventory) The distributor places an order based upon a rule (e.g. place No change distributor actual order = planned distributor order) The wholesaler places an order based upon a rule (e.g. place No change actual wholesaler order = planned wholesaler order) The retailer places an order based upon a rule (e.g. place No change actual retailer order = planned retailer order) The customer places an actual No change order Product is received at distributor No change goods inward location Product is received at wholesaler No change goods inward location
260
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) TO-BE AS-IS description for each process description for each process Product is received at retailer goods inward location No change No practice can be identified, the input provides a workflow No change No practice can be identified, the input provides a workflow No change No practice can be identified, the input provides a workflow No change Beer is received from the factory and stocked at the distributor No change goods receiving location Beer is received from the distributor and stocked at the No change wholesalers goods receiving location Beer is received from the wholesaler and stocked at the retailer No change goods receiving location
PROMOTED PHANTOM PHANTOM PHANTOM
S1.2 S1.3 S1.3 S1.3
Retailer Distributor Wholesaler Retailer
PROMOTED
S1.4
Distributor
PROMOTED
S1.4
Wholesaler
PROMOTED
S1.4
Retailer
PROMOTED
P3
Factory
PROMOTED
M1.1
Factory
SIMPLIFIED PROMOTED PHANTOM
M1.2 M1.3 M1.4
Factory Factory Factory
PROMOTED
M1.5
Factory
PROMOTED
M1.6
Factory
PROMOTED
D1.2
Distributor
CORE
D1.2
Wholesaler
PROMOTED
D1.2
Retailer
PROMOTED
D1.3
Distributor
CORE
D1.3
Wholesaler
PROMOTED
D1.3
Retailer
PROMOTED
D1.5
Factory
The factory schedules production activities based upon rule (e.g. Produce actual factory work order = planned factory work order) Infinite raw materials are available at the factory production Beer is manufactured at the factory No practice can be identified, the input provides a workflow Beer is staged at goods inward awaiting movement to a finished goods location for a one week period The product is released to delivery Order is received from the wholesaler and entered into the distributor order processing system Order is received from retailer and entered into the wholesaler order processing system Order is received from the external customer and entered into the retailers order processing system 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. 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. 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. Transportation is not constrained by load requirements
PROMOTED
D1.5
Distributor
Transportation is not constrained by load requirements
No change
PROMOTED PHANTOM PHANTOM PHANTOM PHANTOM PHANTOM PHANTOM
D1.5 D1.6 D1.6 D1.6 D1.7 D1.7 D1.7
Wholesaler Factory Distributor Wholesaler Factory Distributor Wholesaler
No change No change No change No change No change No change No change
CORE
D1.8
Factory
CORE
D1.8
Distributor
CORE
D1.8
Wholesaler
CORE
D1.8
Retailer
Transportation is not constrained by load requirements No practice can be identified, the input provides a workflow No practice can be identified, the input provides a workflow No practice can be identified, the input provides a workflow No practice can be identified, the input provides a workflow No practice can be identified, the input provides a workflow No practice can be identified, the input provides a workflow Product is received from the factory production and provides the factory finished goods inventory level for calculation of the inventory metric Product is received from the distributors goods receiving and provides the distributors finished goods inventory level for calculation of the inventory metric Product is received from wholesalers goods receiving and provides the wholesaler finished goods inventory level for calculation of the inventory metric Product is received from the retailers goods receiving and provides the retailers finished goods inventory level for calculation of the inventory metric
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)
261
No change
No change No change No change No change No change No change No change No change No change
No change
No change
No change No change
No change
No change
No change
No change
Boundary setting status
Process element
Actor location
PROMOTED
D1.9
Factory
PROMOTED
D1.9
Distributor
PROMOTED
D1.9
Wholesaler
PROMOTED
D1.10
Factory
PROMOTED
D1.10
Distributor
PROMOTED
D1.10
Wholesaler
PROMOTED PROMOTED PROMOTED
D1.11 D1.11 D1.11
Factory Distributor Wholesaler
PROMOTED
D1.12
Distributor
CORE
D1.12
Wholesaler
PROMOTED
D1.12
Factory
CORE
D1.13
Wholesaler
PROMOTED
D1.13
Factory
PROMOTED
D1.13
Distributor
SIMPLIFIED
ED.4
Retailer
SIMPLIFIED
ED.4
Distributor
SIMPLIFIED SIMPLIFIED
ED.4 ED.4
Wholesaler Factory
SIMPLIFIED
EP.3
Factory
SIMPLIFIED
EP.3
Distributor
SIMPLIFIED
EP.3
Wholesaler
SIMPLIFIED
EP.3
Retailer
SIMPLIFIED
ES.4
Distributor
SIMPLIFIED
ES.4
Wholesaler
SIMPLIFIED
ES.4
Retailer
SIMPLIFIED
ED.1
Factory
SIMPLIFIED
ED.1
Distributor
SIMPLIFIED
ED.1
Wholesaler
SIMPLIFIED
ED.1
Retailer
How is each process actually implemented in practice? (noting any practices that cannot be identified, but an input provides a workflow) TO-BE description for each AS-IS description for each process process Factory satisfies all orders placed by the distributor No change Distributor satisfies all orders placed by the No change wholesaler Wholesaler satisfies all orders placed by the No change retailer The factory moves finished goods to stocking No change location The distributor moves finished goods to stocking No change location The wholesaler moves finished goods to stocking No change location The factory places beer onto transportation No change The distributor places beer onto transportation No change The wholesaler places beer onto transportation No change The product (beer) is shipped from the distributor No change to the wholesaler goods inward stock location The product (beer) is shipped from the wholesaler No change to the retailer goods inward stock location The product (beer) is shipped from the factory to No change the distributor goods inward stock location The wholesaler tracks the completeness of the order to produce in the "in-full" aspect of the No change metric The beer supplied by the factory is received by the No change distributor The beer supplied by the distributor is received by No change the wholesaler There are no safety stocks calculated No change The distributor (human) may wish to calculate how much There are no safety stocks calculated safety stock is needed to satisfy demand. There are no safety stocks calculated No change There are no safety stocks calculated No change The factory planning data is collected for No change manufacturing, resource and delivery The distributor planning data is collected for No change manufacturing, resource and delivery The wholesaler planning data is collected for No change manufacturing, resource and delivery The retailer planning data is collect for No change manufacturing, resource and delivery The distributor maintains the goods receiving No change stocking location and target levels The wholesaler maintains the goods receiving No change stocking location and target levels The retailer maintains the goods receiving stocking No change location and target levels Rules are maintained for the factory which affect the acceptance of an order from the distributor No change based on quantity (i.e. orders can range between 0 - 99 barrels of beer) Rules are maintained for the distributor which affect the acceptance of an order from the No change wholesaler based on quantity Rules are maintained at the wholesaler which affect the acceptance of an order from the retailer No change based on quantity Rules are maintained at the retailer which affect the acceptance of an order from the customer No change based on quantity
262
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 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 SS Material requirements plan (MRP) is used to plan blanket orders sent to CHR and T The CHR re-plan "production" kanbans and manufacturing resources The T re-plan "production" kanbans and manufacturing resources
TO-BE 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
CORE
P2
LA
PROMOTED
P2
SS
PROMOTED
P3
CHR
PROMOTED
P3
T
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
No change
No change No change No change
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.
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
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
CORE
S1.1
LA
PROMOTED
S1.1
3PL
CORE
S1.2
LA
PROMOTED
S1.2
3PL
PHANTOM
S1.3
3PL
PHANTOM
S1.4
3PL
PROMOTED
M1.1
CHR
PROMOTED
M1.1
T
PROMOTED
M1.1
SS
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) 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. Product (CHR and T) is received daily at the 3PL warehouse No practice can be identified, the input provides workflow No practice can be identified, the input provides workflow CHR schedules production, using demand-pull production kanban mechanism (kanban from S1.1 at 3PL) T schedules production, using demand-pull production kanban mechanism (kanban from S1.1 at 3PL) The SS produces to DCI (each day with a 10 day horizon) received from the LA
263
No change
No change
No change No change No change No change
No change No change
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 Target launch sequence (TLS) is continuously broadcast from the LA to SS SS Issue material based on 2-bin system from 3PL local stock The CHR assumes infinite raw materials available to produce central headrests The T assumes infinite raw materials available to produce tracks Central head rests are produced and tested using demand-pull mechanisms Tracks are produced and tested using demandpull mechanisms SS assembles and tests rear seats and front seats from line side stock (tracks and central headrests) using demand-pull mechanisms CHR are packaged to minimise damage in transit to SS T are packaged to minimise damage in transit to SS SS are covered in protective sheeting to minimise damage in transit to LA
TO-BE
PROMOTED
M1.1
LA
No change
PROMOTED
M1.2
SS
SIMPLIFIED
M1.2
CHR
SIMPLIFIED
M1.2
T
PROMOTED
M1.3
CHR
PROMOTED
M1.3
T
PROMOTED
M1.3
SS
PROMOTED
M1.4
CHR
PROMOTED
M1.4
T
PROMOTED
M1.4
SS
PROMOTED
M1.5
CHR
Kanban controls the movement of CHR
No change
PROMOTED
M1.5
T
Kanban controls the movement of T
No change No change
No change No change No change No change No change No change No change No change No change
PROMOTED
M1.5
SS
SS are staged awaiting collection for delivery to POU at LA line-side location for seat sets
PROMOTED
M1.6
CHR
Kanban controls the movement of CHR
No change
PROMOTED
M1.6
T
Kanban controls the movement of T
No change
SS are staged awaiting collection for delivery to POU at LA line-side location for seat sets Receive kanban replenishment signal for CHR from the 3PL Receive kanban replenishment signal for T from the 3PL
PROMOTED
M1.6
SS
No change
PROMOTED
D1.2
CHR
PROMOTED
D1.2
T
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 No change
No change No change
PROMOTED
D1.3
SS
Seat sets are sequenced based on the TLS provided by LA
PROMOTED
D1.4
CHR
Kanban controls the movement of CHR
No change
PROMOTED
D1.4
T
Kanban controls the movement of T
No change No change
PROMOTED
D1.4
SS
Seat sets are sequenced based on the TLS provided by LA
PROMOTED
D1.5
CHR
Kanban controls the movement of CHR
No change
PROMOTED
D1.5
T
Kanban controls the movement of T
No change No change
PROMOTED
D1.5
SS
Seat sets are sequenced based on the TLS provided by LA
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
PHANTOM
D1.7
CHR
PROMOTED
D1.9
SS
SS are transported to LA POU in production lineside location No practice can be identified, the input provides workflow SS are transported to LA POU in production lineside location
264
No change No change No change
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 CHR is received from make in loading area for 3PL pick up. Product receipts are recorded. T is received from make in loading area for 3PL pick up. Product receipts are recorded. Seat sets are received from make and put-away in SS warehouse. Product receipts are recorded.
PROMOTED
D1.8
CHR
PROMOTED
D1.8
T
PROMOTED
D1.8
SS
PHANTOM
D1.9
CHR
No practice can be identified, the input provides workflow
PHANTOM
D1.9
T
No practice can be identified, the input provides workflow
PHANTOM
D1.9
SS
No practice can be identified, the input provides workflow
PHANTOM
D1.10
CHR
No practice can be identified, the input provides workflow
PHANTOM
D1.10
T
No practice can be identified, the input provides workflow
PHANTOM
D1.10
SS
No practice can be identified, the input provides workflow
PHANTOM
D1.11
CHR
No practice can be identified, the input provides workflow
PHANTOM
D1.11
T
No practice can be identified, the input provides workflow
PROMOTED
D1.11
SS
Seats sets are loaded in sequence
PROMOTED
D1.12
3PL
3PL ships central headrests and tracks to SS
PROMOTED
D1.12
SS
Seat sets are shipped to POU at LA manufacturing location
PHANTOM
D1.13
3PL
No practice can be identified, the input provides workflow
PHANTOM
D1.14
SS
No practice can be identified, the input provides workflow
PROMOTED
EP.3
CHR
Manufacturing, resource and delivery data
PROMOTED
EP.3
T
Manufacturing, resource and delivery data
PROMOTED
EP.3
SS
Record DCI and TLS requirements
PROMOTED
EP.3
LA
Supply chain execution information is recorded
PROMOTED
ED.4
SS
SS maintains finished goods, and inventory levels for product mix
PROMOTED
ED.4
CHR
CHR maintains finished goods, and inventory levels for product mix
PROMOTED
ED.4
T
T maintains finished goods, and inventory levels for product mix
265
TO-BE No change No change No change No change No change No change No change No change No change No change No change No change No change No change No change No change No change No change No change No change No change No change No change
Appendix D Table D.1 ASIS/ TOBE
Actor that implements practice
Illustrations of model components to be developed into a computer model
Model components for ‘Retailer plan and place order’ (BeerCo development case) How will each actual practice be represented by the components in the computer model? List of consolidated actual practices
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?
From 6.2.1
From 6.2.2 Human player (retailer role): The player exists in the ‘world’ entering the process to plan order in each decision period
from 6.1
ASIS
ASIS
Retailer
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)
The retailer places an order based upon a rule (e.g. place actual retailer order = planned retailer 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
1. 2. 3.
Retailer player places an order for each decision period Accept order if within max order size? If yes, (the order size is within the max order size) then the order is accepted 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 reenters the order. If order is accepted an accepted order is sent to the wholesaler ‘receive order’ process
4.
5.
ASIS
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
266
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)
Comment on any assumptions or simplifications From 6.2.3
Orders are planned in each weekly decision period
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
N/A
Include order acceptance rule based on order max size in place order
Table D.2 ASIS/ TOBE
Actor that implements practice
Model components for ‘Wholesaler Receive and fulfil order’ (BeerCo development case) How will each actual practice be represented by the components in the computer model? List of consolidated actual practices from 6.3.2
What processes, activities or events need to be included in the computer model?
from 6.1 1) 2)
3) 4)
ASIS
Wholesaler
Order is received from retailer and entered into the wholesaler order processing system
From 6.2.1 Receive and add current order from Retailer (Retailer_order) into a queue in date 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 Is inventory available? (Wholesaler_Warehouse.AVAILinv>0) 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)
5)
ASIS
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.
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) If no (inventory is not available), the update backorder status as order cannot be met (Wholesaler_backorder = Wholesaler_onorder)
N/A
267
What entities need to be included to represent the activities or events in the computer model? From 6.2.2
Comment on any assumptions or simplifications From 6.2.3
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
N/A
Assume inventory management is part of the receive and fulfil process
Appendix E
Example process flow diagrams for the BeerCo development case
World Player: Human player (retailer role)
Player: Human player (retailer role)
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
Retailer player places an order for each decision period Retailer_order Retailer max order qty: Retailer_order.max
Accept order if within max order size?
Yes
No
The player is informed that the order cannot be permitted
The order is accepted Accepted order Retailer_order
Reject order Retailer_order
An order is sent to the wholesaler ‘receive order’ process Retailer_order
To Wholesaler ‘receive order’
Figure E.1
Retailer plan and place order in BeerCo development case
268
W1
From Retailer plan and place
Receive and add current order from Retailer (Retailer_order) into a queue in date order
Retailer’s order: Retailer_order.qty Retailer_order.date
Retailer_order
Check to see if any backorders remain (Wholesaler_backorder>0) and create Wholesaler_onorder
Wholesaler backorder: Wholesaler_backorder
Wholesaler_onorder = Retailer_order.qty + Wholesaler_backorder Current order: Wholesaler_onorder Available inventory in Warehouse: Wholesaler_Warehouse.AVAILinv
Is inventory available?
Wholesaler_Warehouse.AVAILinv>0 Wholesaler_onorder Yes
No
No
Calculate how much of the order can Yes be satisfied and create delivery order
Update backorder status as order cannot be met
Wholesaler_deliveryorder = Min (Wholesaler_warehouse.AVAILinv; Wholesaler_onorder)
Wholesaler_backorder = Wholesaler_onorder
Wholesaler_deliveryorder
Wholesaler_backorder
Can the order be satisfied in full? Yes
Order is complete
eWholesaler_order
No Create an unsatisfied order as only part of the order is satisfied (Wholesaler_order.unsatisfied = Wholesaler_onorder – Wholesaler_deliveryorder) Wholesaler_order.unsatisfied
Update backorder status (Wholesaler_backorder = Wholesaler_order.unsatisfied) Terminate
Figure E.2
Wholesaler_backorder
Fulfil order in BeerCo development case
269
Backorder status
Appendix F model
Figure F.1
Flowchart of the CoffeePotCo computer simulation
Flowchart of computer simulation program for CoffeePotCo
Source: Taylor et al., (2008, pg. 5)
270
Appendix G Table G.1
Comparison of practice to be modelled and CoffeePotCo computer model
AS-IS Scenario in CoffeePot Co validation case for the ‘Customer’
Actual practice to be modelled 2
Representation in computer model
Outcome from 6.1 in the SCM
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).
271
Comments on any omissions or differences
Not significant, orders are sent continuously and independently of one another.
Table G.2
AS-IS Scenario in CoffeePotCo validation case for the ‘Warehouse’ Actual practice to be modelled Outcome from 6.1 in the SCM2
The warehouse determines whether or not to place an order with the factory for finished goods replenishment using an (R, r) policy.
Representation in computer model From Taylor et al., (2008) 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.
Comments on any omissions or differences
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. 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. 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.
272
Backorders when
Value of finished goods stock is
Table G.3
AS-IS Scenario in CoffeePotCo validation case for the ‘Factory’
Actual practice to be modelled Outcome from 6.1 in the SCM2 The factory delivery plan, factory production plan and factory production schedule = the actual order from the warehouse Assume raw materials are available to factory production process
Representation in computer model From Taylor et al., (2008) The model is actualised by entities representing demand (actual order)
No difference
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 The factory loads the product onto the ship or aircraft depending upon the option
The product is shipped to the warehouse from the factory The product is received from the factory to the warehouse location.
It is assumed that the factory produces based upon satisfying the next order in queue. The product is loaded depending upon shipment method constraints (e.g. container size varies between ship and aircraft) 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). Moves directly to finished good stock
273
Comments on any omissions or differences
Not significant, next order collected Not significant, product is loaded dependent on shipping method 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. Not significant, product is received at the warehouse
Table G.4
TO-BE Scenario in CoffeePotCo validation case for the ‘Factory’
Actual practice to be modelled Outcome from 6.1 in the SCM2
The factory consolidate 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
Representation in computer model From Taylor et al., (2008)
Comments on any omissions or differences
Yes, orders are consolidated to suit container size.
Not significant
Yes, orders are collected in the desired amount (“large” in this case) depending upon shipping method.
Not significant
Packing time is not included.
Significant, the packing time has not been included. This would vary depending upon shipping method and container size.
274
Appendix H Table H.1
Evaluation of how information is used and provided in the preliminary validation case 2
Evaluation of how the SCM uses information 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).
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.
Ph.
3
Information required by the SCM2
275
Ph.
Information required by the SCM2
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
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
6
7
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 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
Information provided by the SCM2 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 List of PROMOTED, SIMPLIFIED, TO TEST, or EXCLUDED process elements (with justification) Above are verified
Comments on following the steps in the SCM2 for the CoffeePotCo validation case 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. 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.
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.
Draft and validate a nonsoftware specific description of the simulation model to be developed Issues that have arisen in the validation steps
Not evaluated
276
Appendix I Issues for testing the ‘usability’ of the SCM2 Table I.1 Issues for testing the ‘usability’ of the SCM
Clarity
Ease of use
Appropriateness
2
Observations from applying the SCM2 to the CoffeePotCo validation case 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 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 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
277
Issues for future refinement and testing 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)
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 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.
