1. Decision Technology Modeling, Software and Applications Matthew J. Liberatore Robert L. Nydick John Wiley & Sons, Inc.

2. Chapter 15 Process Redesign Using Extend

3. PROCESS REDESIGN The previous chapter showed how Extend could be used to simulate a wide variety of applications. While this is important, it is even more important to use simulation to help make decisions. The purpose of this chapter is to show how the output from simulation models can be used to improve the decision-making process.

4. PROCESS REDESIGN: CAR WASH A series of car wash models illustrate how simulation can identify issues that lead to process redesign. The first model (CARWASH1.MOX) considers a car wash with one bay which just washes cars. Interarrival times are exponential with a mean of 4 minutes, while service time is constant at 6 minutes.

5. This model is similar to BANK1T.MOX except the delay is set to 6 in Activity, Multiple. What happens to line lengths when this model is run? Lines continue to grow because the time to wash a car is longer than the average interarrival time. CARWASH2.MOX adds a second bay to reduce lines. PROCESS REDESIGN: CAR WASH

6. The customer usually has the option of having wax applied after the wash. We model this situation by adding an attribute to the cars coming from the Generator block, then checking for that attribute as the car gets washed. PROCESS REDESIGN: CAR WASH

7. We name the first attribute in Set Attribute (DE.LIX, Attributes) as “type” (“Attribute” tab). Assume that 75% of the cars are no wax (type equals 0) and 25% are wax (type equals 1). Input Random Number is used to randomly generate type which is passed to the “A” connector of Set Attribute. PROCESS REDESIGN: CAR WASH

8. The customer enter the Queue, FIFO tagged as a wax (1) or no wax (0) customer. We use Get Attribute (DE.LIX, Attribute) to retrieve type to decide whether the customer is sent to top bay (wash only) or bottom bay (wash and wax). PROCESS REDESIGN: CAR WASH

9. The attribute is passed to Select DE Output so that the cars are routed to the correct bay. Service time for wash only is 6 minutes and 8 minutes for wash and wax. This model is in a file called CARWASH3.MOX. PROCESS REDESIGN: CAR WASH

10. What is WQ and how many cars use each car wash? WQ is 79.06 minutes and continues to increase. An alternate approach is to use a Generator for each type of customer. Over a 16 minute interval there will be 3 wash only and 1 wash and wax arrivals, on average. 1/ equals 16/3 = 5.33 minutes for wash only and 16/1 = 16 minutes for wash and wax. PROCESS REDESIGN: CAR WASH

11. Once an arrival is generated, we set type as before and merge the two arrival streams into a queue using Combine (DE.LIX, Routing). This model is in a file called CARWASH3G2.MOX. The line length and waiting time patterns for CARWASH3.MOX and CARWASH3G2.MOX are similar, as expected. PROCESS REDESIGN: CAR WASH

12. What is the problem with this process design? Suppose the second customer in line wants a wash only and the first customer wants a wash and wax. If, the wash only bay is available and the wash and wax bay is occupied, then the second customer must wait until the first customer begins service. PROCESS REDESIGN: CAR WASH

13. How can this design be improved? Both bays need to be able to wash only or wash and wax. This requires an investment that can only be justified if the additional profit generated will cover the cost over a reasonable period of time. This redesigned model appears in CARWASH4.MOX. PROCESS REDESIGN: CAR WASH

14. This model is similar to CARWASH1.MOX except that Maximum number is activity is set to 2 in Activity, Multiple. We use Input Random Number is used to specify that 75% of the time the delay is 6 and 25% of the time the delay is 8. What is WQ for this redesigned car wash? WQ is 3.67 minutes and line length and waiting times are stabilized. PROCESS REDESIGN: CAR WASH

15. SIMULATION COST ANALYSIS We will now show how simulation can be used to improve the decision-making process. Consider the following example that shows the fundamental trade-off between the cost of providing service and the cost of waiting. A petroleum company is considering expansion of its one unloading facility at its refinery. The interarrival time follows the exponential distribution where the mean interarrival time is 1 day.

16. SIMULATION COST ANALYSIS Service time is Erlang distributed with a mean service time of 0.5 days with a k value of 6. Loading berths are rented at a cost of $1000 per day per berth. A ship’s waiting time is worth $5,000 per day and is assessed while the ship is waiting in the queue and while it is being serviced.

17. SIMULATION COST ANALYSIS Simulate 365 days of operation and repeat for 50 years. How many additional berths, if any, should be rented? We modify BANK1T.MOX to model this problem. In Generator (“Cost” tab), we enter $5000 in the Waiting cost per time unit location. Check the box Calculate waiting costs in Queue, FIFO (“Queue” tab).

18. SIMULATION COST ANALYSIS In Activity, Multiple (“Cost” tab), we again enter $5000 in the Waiting cost per time unit location. If there is only a charge for waiting in line, do not enter a cost value in Activity, Multiple. Add Cost Stats (STATS.LIX, none) to compute the average cost to wait in line and the average cost to wait during service. Computing the confidence intervals in the Cost Stats block shows the average costs.

19. SIMULATION COST ANALYSIS Extend keeps track of the amount of time that each arrival spends in the queue and multiplies that by $5000. These results are summed for all arrivals. A similar process is used to compute the average service cost. The results of a single server model are in LOADING1.MOX.

20. SIMULATION COST ANALYSIS These results show that, over 50 years, the average waiting cost in the queue is $536,600 while the average cost during service is $912,700 for an average total waiting cost of $1,449,300 per year. Since berths are being rented at $1000 per day (1000*365=365,000), the average total cost (ATC) is $1,814,300 per year.

21. SIMULATION COST ANALYSIS The results of a two server model are in Loading2.mox. The average waiting cost in the queue has dropped dramatically to $41,640, while the average waiting cost during service is $911,800 (roughly the same as Loading1.mox). The rental cost for the berths is $2000 per day, therefore, the ATC per year=$41,640+911,800+730,000=$1,683,440.

22. SIMULATION COST ANALYSIS The results of a 3 server model are in Loading3.mox. The average waiting cost in the queue has dropped to $4,715, while the average waiting cost during service is $911,300. The rental cost for the berths is $3000 per day, therefore, the ATC per year=$4,715+911,300+1,095,000=$2,011,015.

23. SIMULATION COST ANALYSIS The summary of the three models are: ATC per year (1 berth) = $1,814,300 ATC per year (2 berths) = $1,683,440 ATC per year (3 berths) = $2,011,015 It is recommended that 2 berths be used.

24. SIMULATION COST ANALYSIS After thinking about these results, why was it unnecessary to run the analysis for three berths? In LOADING2.MOX, the average waiting cost in the queue is $41,640. Even if this number would drop to zero when a third berth is added, you would still incur $365,000 ($1000*365) for renting the additional berth. This amount is far greater than the potential savings in waiting cost.

25. SERVICE LEVEL: SUBWAY Often, waiting costs cannot be easily estimated. In such situations, we can study service levels. Earlier, we used Extend to estimate the percentage of customers who waited more than 10 minutes in line. Consider the following example that uses another service level measure to determine the number of servers.

26. SERVICE LEVEL: SUBWAY A subway uses computerized turnstiles to collect fares. Customers insert their cards into turnstiles upon entering or leaving the train. For example, if a ride costs $0.75 and the passenger has a $10.00 card, the exit turnstile would print $9.25 as the remaining value on the card. Our subway station has six turnstiles, each of which can be used for either entrance or exit, but never for both.

27. SERVICE LEVEL: SUBWAY Between 7:00 and 9:00 AM the interarrival times for entering and exiting passengers are exponential with means of 0.714 and 1.25 seconds, respectively. Service time is always Erlang with a mean of 2 seconds per customer and a k of 4, regardless of direction. Assume that riders form a common queue at both entry and exit and then proceed to the first available turnstile. The manager wants the average passenger to not wait in any queue for more than 5 seconds.

28. How many turnstiles should be open in each direction? Entering 1/ = 0.714 seconds per customer. 1/  = 2 seconds per customer. N is the smallest integer greater than 2/0.714 = 2.80 or 3. This means that we need at least 3 entering turnstiles. SERVICE LEVEL: SUBWAY

29. Exiting 1/ = 1.25 seconds per customer. 1/  = 2 seconds per customer. N is the smallest integer greater than 2/1.25 = 1.60 or 2. This means that we need at least 2 exiting turnstiles. SERVICE LEVEL: SUBWAY

30. The model needed for this problem is virtually identical to BANK1T.MOX with a few changes. We simulated the two-hour period for 10 days. Entering The results of the three server model are in SUBENT3.MOX. The results show that the 95% confidence interval for WQ for the 10 runs is 5.48 +/- 0.913 seconds. SERVICE LEVEL: SUBWAY

31. This implies that we are 95% confident that the population WQ is between 4.567 and 6.393. This indicates that it quite probable that WQ will be over five seconds and is unacceptable. The results of the 4 server model are in SUBENT4.MOX. The results show that the 95% confidence interval for WQ for the 10 runs is between 0.4148 and 0.4812 seconds and is acceptable. SERVICE LEVEL: SUBWAY

32. Exiting The results of the two server model are in SUBEXIT2.MOX. The results show that the 95% confidence interval for WQ for the 10 runs is between 2.004 and 2.256 seconds and is acceptable. Therefore, open 4 turnstiles in the entering direction and 2 in the exiting. SERVICE LEVEL: SUBWAY

33. What simplifying assumptions are you making? What happens if a fare is $0.75 and someone only has $0.60 on their card? Attributes can be used to model this situation. The station probably has a queue behind each turnstile and reneging and balking may occur. The BANK models can be used for these types of variation. SERVICE LEVEL: SUBWAY

34. Do arrivals occur in batches? This is often the case in this type of situation as passengers are delivered in batches to trains from other trains and buses. In this situation we must model not only the time between arrivals, but the number of arrivals in each batch as in BANKCYCLE.MOX. SERVICE LEVEL: SUBWAY

35. In the loading example, we used trial and error to determine that 2 loading berths were needed. Extend provides an optimization feature to automatically optimize values for different parameters. This feature can be used to have Extend evaluate different number of berths to minimize cost. OPTIMIZATION WITH EXTEND

36. There is no guarantee that the optimal solution will be found since we are simulating, however, this is better than trial and error. Extend warns: “Optimization is not fool-proof! Any optimizer can converge to a sub-optimal solution, especially if it is not run long enough. It is recommended that at least 100 generations are used, and the case should be run several times with convergence to the same or near solution before that solution is actually used.” One other cautionary note – optimization may take a long time! OPTIMIZATION WITH EXTEND

37. The Evolutionary Optimizer (Optimizer.lix, none) can be added to any model and is not connected to any other block. Usually an objective function (e.g., cost or profit) is entered since this is what is being optimized and constraints can also be entered. According to Extend: “Each solution is tried by running the model several times, averaging the samples, and sorting the solutions. The best solution sets of parameters are used to derive slightly different solutions that might be better. Each new derived solution is called a generation. This process continues for enough generations until there are probably no better solutions in sight.” OPTIMIZATION WITH EXTEND

38. Here is a brief overview of the steps to optimize: 1. Open a model to be optimized 2. Place the Evolutionary Optimizer in the model 3. Define a profit or cost equation – objective function 4. Drag variables needed to the closed Evolutionary Optimizer block 5. Set any limits in the Optimizer’s dialog 6. Enter the objective function in the Optimizer’s dialog 7. Enter constraints, if needed 8. Select “Quicker Defaults, Random Model” or “Better Defaults, Random Model” in the Optimizer Parameters tab 9. Click on the Results tab of the Evolutionary Optimizer 10. Select the “Run Optimization” button (to the right of the green “Run Simulation” button on toolbar OPTIMIZATION WITH EXTEND

39. Use Loading1.mox and place the Evolutionary Optimizer block in the model. Cost is computed as total waiting cost ($5,000 per day for each ship) plus the cost for the loading berths ($1,000 per day for each berth). Multiply 1000 by the number of berths to compute the cost for the berths. Computing the waiting cost is more involved. OPTIMIZATION: LOADING

40. To compute waiting cost you do not multiply WQ+WS by 5000 – you multiply LQ+LS by 5000. To explain why this is so, suppose for the first three days we have 3, 2, and 4 ships in the queue. This means that we incur $15000 (3*5000), 10000 (2*5000), and 20000 (4*5000) in waiting costs for the three days. The same logic is used for waiting cost during service. OPTIMIZATION: LOADING

41. Place LQ from Queue, Fifo, LS and Maximum number in activity from Activity, Multiple in the Evolutionary Optimizer block using the clone tool. LQ is var0, LS is var1, and the number of berths is var2. The objective function is entered as mincost=5000*(var0+var1)+1000*var2; Tell the optimizer what values it can change by entering Min Limit (1) and Max Limit (3) for var2 (# of berths). OPTIMIZATION: LOADING

42. Run the model by selecting “Quicker Defaults, Random Model” or “Better Defaults, Random Model” in the Optimizer Parameters tab. (The latter will take longer to run.) The results tab (Loadingopt.mox) show the best solution that two berths should be used (var2 in row 0). The total cost is $4488.11 per day or $1,638,160.15 per year. (The results from Loading2.mox were $1,683,440 per year.) The number of servers was also changed in Activity, Multiple. OPTIMIZATION: LOADING

43. A tollbooth offers EZ Pass where the interarrival time is exponential with a mean of 7 seconds. EZ Pass customers always use EZ Pass Lanes, and vise- versa for non-EZ Pass customers. Service times for EZ Pass and non-EZ Pass customers are both Erlang with means of 2 and 28 seconds and a k’s of 5 and 5, respectively. The goal is to identify the percentage of EZ Pass people that will minimize the total amount of waiting time (see Tollopt.mox and Select DE Output). OPTIMIZATION: TOLLBOOTH

44. The information that is entered in the Evolutionary Optimizer is the probability for non-EZ Pass customers (var0) and the WQ values for the non EZ Pass line (var1) and the EZ Pass line (var2). Since the decision variable is the percentage of customers using the non EZ Pass line, limits of 0.001 and 0.999 are entered. The objective is to: mincost=var1+var2. The results show that the ideal percentage of non EZ Pass customers is 0.162 (percentage of EZ Pass is 0.838) with a total waiting time of 5.64 seconds. OPTIMIZATION: TOLLBOOTH

45. SUMMARY  In this chapter, we:  Showed how the output from simulation models can be used to improve the decision- making process.  Specific areas covered include: car wash, economic and service level analysis, and optimization with Extend.

46. COPYRIGHT Copyright  2003 Matthew J. Liberatore and Robert L. Nydick. All rights reserved. Reproduction or translation of this work beyond that named in Section 117 of the United States Copyright Act without the express written consent of the copyright owners is unlawful. Requests for further information should be addressed to Matthew J. Liberatore and Robert L. Nydick. Adopters of the textbook are granted permission to make back-up copies for their own use only, to make copies for distribution to students of the course the textbook is used in, and to modify this material to best suit their instructional needs. Under no circumstances can copies be made for resale. Matthew J. Liberatore and Robert L. Nydick assume no responsibility for errors, omissions, or damages, caused by the use of these programs or from the use of the information contained herein.