Simulation with Arena: Detailed Modeling, Error Detection, and Performance Measurement, Slides of Banking and Finance

Download Simulation with Arena: Detailed Modeling, Error Detection, and Performance Measurement and more Slides Banking and Finance in PDF only on Docsity! Simulation with Arena Chapter 5 – Detailed Modeling and Terminating Statistical Analysis Slide 45 of 88 Submodel Logic • Delay for call – Delay module • Decide if Sales person required – Decide module • If sales person is required  Seize sales person – Seize module, shared queue  Follow-up delay – Delay module  Release sales person – Release module • Record call – Record module  Elapsed time from call’s arrival to system up to now • Release trunk line – Release Module • Dispose of entity – Dispose module Docsity.com Simulation with Arena Chapter 5 – Detailed Modeling and Terminating Statistical Analysis Slide 46 of 88 Finding and Fixing Model Errors • Arena picks up “simple” errors in Check phase, and leads you to them via Find and Edit buttons in Errors/Warnings windows  Undefined variables, attributes, resources  Unconnected modules  Duplicate module names  Typos • Other kinds of errors are more complex, can’t be detected without trying to run — options on Run Interaction toolbar or on Run menu • Only mention capabilities here; see text for details Docsity.com Simulation with Arena Chapter 5 – Detailed Modeling and Terminating Statistical Analysis Slide 49 of 88 Model 5-2: Animating the Model • No “normal” entity animation — just plots, queues, a few other “data” animations • Plots (all vs. time on horizontal axis)  Queue lengths (as in earlier models)  Balks per period — reason for variable Per Period Balk  Number of tech support people available for each product type — reason for the “Available” expressions defined in Expressions module  With multiple plots, configure first one, then copy/edit for others to get consistent look and feel; snap to grid to align • Variable animations for Period and Day Docsity.com Simulation with Arena Chapter 5 – Detailed Modeling and Terminating Statistical Analysis Slide 50 of 88 Animating the Model (cont’d.) • Created digital clock “by hand” (details in text)  Why not ready-made animated clocks? We didn’t reset the system state between replications, so internal clock just keeps increasing • Resource and queue animations • Just for realism — doesn’t add any analysis value • Resource button from Animate toolbar  Take pictures from libraries (.plb files), different states • Queue button from Animate toolbar • Add various text annotations, boxes, etc. Docsity.com Simulation with Arena Chapter 5 – Detailed Modeling and Terminating Statistical Analysis Slide 51 of 88 Animating the Model (cont’d.) • Storages for further animation  Requires using Delay modules from Blocks panel, not Advanced Process panel – We did this only for the delay listening to the first recorded message  Enter a Storage name in the Blocks Delay module (Message 1)  Storage button from Animate Transfer toolbar • Animated variables  Number of available trunk lines  Number of available salespeople  Number of sales calls in progress Docsity.com Simulation with Arena Chapter 5 – Detailed Modeling and Terminating Statistical Analysis Slide 54 of 88 Slimming Down and Speeding Up • Academic version places several different kinds of limits on model “size”  Max of 150 concurrent entities … though millions could pass through … this limit is not a problem here  Max of 150 “module instances” … includes flowchart modules, and each entry (line) in data modules … this limit is a problem  Also need room to add new output performance measures • Reduce number of module instances  Eliminate many statistical accumulators … included getting rid of lines in data modules, entire flowchart modules, and unchecking stat-collection boxes … details in book • This also increased speed by factor of 3 to 4  Important since this model will be exercised intensively Docsity.com Simulation with Arena Chapter 5 – Detailed Modeling and Terminating Statistical Analysis Slide 55 of 88 Overall Performance Measures • Form an overall cost measure – reduce, minimize  What controllable input parameters affect cost? How? • Two components to cost  Due to staffing and resources – tangible, measurable  Due to poor customer service – intangible, hard to measure • Staffing and resource costs  Hourly salaries: $18 for sales, $16 to $20 for tech-support depending on training (see Resource data module) – Salaries paid whenever person is on duty, whether busy or not  Get current weekly payroll of $13,110 = Staff Cost variable Docsity.com Simulation with Arena Chapter 5 – Detailed Modeling and Terminating Statistical Analysis Slide 56 of 88 Generalize for More Staff • Try to improve service via more staff  Will certainly increase staff cost  Try to improve customer service to make it worthwhile • Base-model results – worst staffing shortfalls are between 11:30AM and 3:30PM • Add sales and tech-support staff for that four- hour period (half-hours 8 through 15) Docsity.com Simulation with Arena Chapter 5 – Detailed Modeling and Terminating Statistical Analysis Slide 59 of 88 Changing the Number of Trunk Lines • Each trunk line costs a flat $89/week, including all calls (even long-distance) • Is 26 the right number? • To change it, just edit the Capacity entry in the Resource data module • Add variable Line Cost to be $89, multiply by number of trunk lines (MR(Trunk Line)) to get weekly cost of trunk lines Docsity.com Simulation with Arena Chapter 5 – Detailed Modeling and Terminating Statistical Analysis Slide 60 of 88 Total New Resource Cost • Define an Expression called New Res Cost: New Sales * New Sales Cost + (New Tech 1 + New Tech 2 + New Tech 3) * LMC Cost + New Tech All * Her Cost + Line Cost * MR(Trunk Line) • Does not depend on what happens during simulation … used only at end in Statistic module • Does not include cost of the base-model human staff (sales, tech-support) … viewed as sunk, and constant for all variants of staffing changes Docsity.com Simulation with Arena Chapter 5 – Detailed Modeling and Terminating Statistical Analysis Slide 61 of 88 Costs for Putting Customers on Hold • Impute a cost for making customers wait on hold  Trade off against resource costs  Use model to understand, improve, optimize this tradeoff  Such customer-dissatisfaction costs are hard to quantify • People have a “tolerance” for holding  Tech-support calls: 3 minutes (variable Tolerance Tech)  Sales calls: 1 min. (Tolerance Sales)  Order-status calls: 2 min. (Tolerance Order Status) • Beyond the tolerance point, system incurs cost of  Tech-support calls: $1.67/min. (variable TWT Cost)  Sales calls: $3.72/min. (SWT Cost)  Order-status calls: $1.58/min. (OSWT Cost) Docsity.com Simulation with Arena Chapter 5 – Detailed Modeling and Terminating Statistical Analysis Slide 64 of 88 Percent-Busy Requirement • Above cost performance measure ignores calls balked away due to no trunk line … busy signal  Clearly, undesirable – very hard to put a cost on it  Instead, have a strong goal to limit this to no more than 5% of incoming calls … a model configuration not satisfying this will be deemed unacceptable no matter how attractive (low) the cost may be  Like a constraint except it’s on an output, not an input … call it a requirement • Compute via two Record modules in arrival submodel to count incoming and balked calls … and Percent Busy line in Statistic module Docsity.com Simulation with Arena Chapter 5 – Detailed Modeling and Terminating Statistical Analysis Slide 65 of 88 Aside – Generality of Models • We could have done a lot of things in very different ways in this model  Using Arena’s costing functions more and doing fewer of our own external calculations  Reparameterize using only “primitive” parameters (e.g., hourly wage rates) and programming Arena to do the calculations • How much of this you do depends on model’s intended use and users • Tradeoff between generality (elegance?) vs. time spent building the model Docsity.com Simulation with Arena Chapter 5 – Detailed Modeling and Terminating Statistical Analysis Slide 66 of 88 Results • Base case (no more people, 26 trunk lines)  Total cost (for the week) = $34K  Percent busy signals = 11% (unacceptable) • Added one resource unit for each type  New Sales, New Tech 1, New Tech 2, New Tech 3, New Tech All, and go to 27 trunk lines  Total cost (for the week) = $28K – Added resources reduced customer waiting time by more than enough to cover their cost  Percent busy signals = 3% (acceptable) – Extra trunk line, plus added resources to move calls through • Is the modification truly and reliably better??? Docsity.com