SM Pizza Report

8/6/2019 SM Pizza Report

1/33

Sally Models SM Pizza Shop

Paul Crane

Randall Frost

Richard Ivey

INSY 3420 Simulation

Submitted to

Dr. Jeff Smith & Volkan Ustun

May 1, 2006


2/33

Contents

1 INTRODUCTION 1

2 METHODOLOGIES 2

3 RESULTS & RECOMMENDATIONS 3

4 APPENDIX I - Arena Model 5

4.1 MODEL CONCEPTUALIZATION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

4.2 MODEL DEVELOPMENT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

4.2.1 Create Order Submodel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

4.2.2 Pizza Making Submodel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

4.2.3 Oven Loading Submodel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

4.2.4 Oven Unloading Submodel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4.2.5 Delivery or Carry-out Submodel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154.2.6 Terminating Condition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4.3 VERIFICATION & VALIDATION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

5 APPENDIX II - Model Analysis 22

5.1 OUTPUT ANALYSIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

6 APPENDIX III - Results and Conclusions 27

6.1 RESULTS & CONCLUSIONS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

7 APPENDIX V - Future Improvements 28

8 APPENDIX VI - Raw Data 29

i


3/33

EXECUTIVE SUMMARY

This paper presents the design and performance evaluation of a pizza shop in which certain criterion are

predetermined. Miss Sally Model, the owner of over 300 pizza stores, is interested in improving the current

configurations of her pizza stores. In this study, an expansion program is considered to minimize totalcost of the shop and maximize customer satisfaction. An overview of how the model was created and how

recommendations were arrived upon can be found in sections 1, 2, and 3. A more in-depth discussion of

the simulation aspects of the modeling can be found in the sections that follow. These sections include how

the model was conceptualized, developed, verified, validated, and analyzed, as well as some additional data

defined from the model.

ii


4/33

1 INTRODUCTION

Pizza shop owner, Miss Sally Model, is interested in optimizing the configurations of her pizza stores.

She currently owns over 300 stores and is undertaking in a major expansion program that will attempt to

minimize total cost while maximizing customer satisfaction. Miss Sally is looking to expand her store intoa national chain, and wishes to determine the amount of workers she should hire and the optimum size oven

she should use for each facility. It is assumed that each of the stores have a peak demand time for three

hours in the evening. Miss Sallys shops cater to prominently suburban areas; therefore, each store offers

carry-out and delivery services for limited dinnertime hours. In this report, only the three hour peak demand

will be taken into account. It has been determined that the stores should hire the same staff for the full three

hour period, although the peak demand occurs for 15 to 45 of these three hours. The front and tail end of

the three hour time frame will be devoted to the workers setting up and cleaning, respectively.

Each pizza shop has five operations. A brief explanation of each the operations can be found belowwhile detailed descriptions can be found in section 4.1.

Order taking A sophisticated phone ordering device is used to process customer orders. The system is

fully functional and therefore will not be analyzed as a portion of this study. However, historical data

taken from the ordering system will be used for classification of pizzas, specifically the batch size of

the pizzas, (batches of one, two, or three pizzas), pizza size (small, medium, or large), and delivery

versus carry-out orders.

Pizza making Pizzas are made at a standard work table and can utilize up to three workers. The three stepsin making the pizzas are listed below.

Dough and saucing

Adding primary ingredients

Adding final ingredients

Standardized times are provided by Sally that have been broken up task and pizza size. These times

will be used in the analysis phase in order to provide Sally with recommendations to how many pizza

makers should be utilized.

Oven baking The oven consists of a conveyor that is controlled by a chute that feeds the baking mech-

anism. The load area of the conveyor is constrained according to the model of the oven and delays

the pizza for 1.9 minutes. Once the pizza is placed on the load area, it then goes down an inclined

chute where it enters the baking area and is cooked for 7.5 minutes. It is then fed into the unload area.

The current model being used by Sally is the Series I oven; however, the load area of the oven can

1


5/33

be increased by purchasing a Series II or III oven. The capital cost of purchasing a Series II oven is

$35,000 while the capital cost of the Series III oven is $65,000. Each of the three oven models will be

considered in the analysis of the pizza shop.

Cutting and boxing One worker is in charge of cutting and boxing a pizza. Another task for this worker is

to make pizza boxes when they are depleting. The shop will start each day with 30 boxes on hand as

there is limited capacity at the unload area. When the unload worker notices there are less than five

boxes, he/she will make boxes. Delivery workers also assist with box making when less than 5 boxes

are readily available, assuming they are not making a delivery. The cutting and boxing task has been

assigned a standard time depending on statistics that were given by Miss Sally. Further explanation

about this standardized time can be found in section 4.1.

Delivery or carry-out As previously mentioned, orders are classified as delivery or carry-out when the

phone order is placed. The portion of the orders that are of the delivery variety (40%) are sent to

the delivery area while the carry-out orders are sent to the front counter. The shop can hire as many

delivery drivers as needed. The drivers deliver one pizza at a time and as previously mentioned, they

also assist with box making when needed. A standard for one way driving time has been provided by

Miss Sally.

2 METHODOLOGIES

The peak demand that spans 15 to 45 minutes will be considered for three hours. The purpose of this

modelling concept is that if the pizza shop can run at full functionality for three hours of peak demand,

it will definitely be able to handle 15 to 45 minutes. A Rockwell Software package, Arena, was used to

simulate Sallys pizza making operation. More about the modelling concepts can be found in section 4.2.

The objective of this simulation was to assist in deciding the configuration of the pizza shop, based on

varying demand rates. The input parameters analyzed include the following:

Number of workers making pizzas

Oven model

Number of delivery drivers

Decisions about the system are made to satisfy 90 - 95% of the customer orders, and are reported below

in section 3.

2


6/33

3 RESULTS & RECOMMENDATIONS

As requested by Miss Sally, Table 1 provides the breakpoints at which peak demands to change the config-

urations the shop in order to operate at the most economical level. The table should be read in the following

manner. To obtain a customer satisfaction level of 90% or greater, determine what the expected peak demandper hour for the store that is to be opened. For that specified peak demand, look at the table, choose the de-

mand level that matches, and configure the shop with parameters listed on that row. If the specified demand

point is not listed in the table, choose the demand level that is immediately higher and use the configurations

of that row. For example, if the expected demand for a new store is 21 customers per hour, the row that has

22 customers per hour should be chosen. Therefore, Sally should use 2 pizza makers, 2 delivery workers,

and the 435 oven size for this store. Note that an average satisfaction of greater than 90% can be expected

in these cases. Sally should heed to the warning that if she expects demand at 22 customers per hour and

is not confident of this forecasted demand, she should choose the next highest configuration to account for

forecast error.

Customers Number of Number of Expected

per Pizza Delivery Oven Satisfaction Expected

Hour Makers Workers Size Level Cost

20 1 2 435 90.81 % $79.05

23 2 2 435 90.34 % $97.50

35 2 3 435 90.90 % $118.95

36 2 3 520 90.40 % $138.39

41 2 4 435 90.65 % $140.40

44 2 4 520 92.24 % $159.84

46 3 4 520 90.28 % $178.2947 2 5 520 90.49 % $181.29

49 3 4 605 90.70 % $194.96

58 3 5 605 90.38 % $216.41

60 3 6 605 92.01 % $237.86

Table 1: Recommended configuration switch-points for Sally

It should be noted that the specified configurations listed in Table 1 have only taken into account the

number of pizza makers, number of delivery workers, and oven series. There will be other parameters that

enter in the final decision making process, and these should also be taken into account. For example, if

growth is expected in the area of the pizza shop, a larger oven should be considered. This would allow

for expansion of the shop. Therefore, Sally should skip to the closest configuration with a larger oven

(i.e. if Sally expects expansion and forecasts a demand of 27 customers per hour, she should build for

the specifications included in the expected demand of 36 customers per hour). For further analysis on

the decision making process, including the effect of choosing the next switch-point up, please refer to

sections 5.1 & 6.1.

3


7/33

According to the study, future improvements can be made to the shop to improve performance and in

turn, increase profitability. It should be noted that the following recommendations have not been studied

rigorously and will require further analysis prior to implementation.

1. The most important recommendation is to allow delivery drivers to deliver multiple orders at a time.

Based on discussions with local pizza stores, delivery drivers can handle up to five or six orders in

each trip, depending on the location of the deliveries.

2. Provide a detailed training session for each worker, educating the pizza makers on each of the three

processes. This will create a more flexible work environment in which workers can assist each other

on the make table. If multiple workers are utilized in a shop, blocking (workers being delayed) and

starving (workers becoming idle) can drastically decrease productivity and can cause many problems

including but not limited to, a bottleneck in the pizza making process.

3. When orders are taken, a labeling process should be implemented that would allow the unload worker

and delivery drivers to prioritize delivery orders in order for them not to be late. The label would

be placed on the pizza box that would include the time of the order. When being boxed, the unload

worker should check all delivery orders and organize the orders in such a way that the delivery workers

are optimized (i.e. grouping pizzas with similar delivery locations).

4. The unload worker could be cross-trained to assist in the pizza making process when idle.

For further analysis, please see sections 5.1 & 6.1.

4


8/33

4 APPENDIX I - Arena Model

4.1 MODEL CONCEPTUALIZATION

In preparing for the simulation modeling process, many preliminary steps were taken before implementingthe logic in Arena. First, each of the team members thoroughly read the assignments and formulated initial

ideas. A group meeting was then held in order to define the scope of the project and subtasks. A general

flowchart of the pizza making process was then constructed to enable the members to visualize the system

as a whole. A replication of the flowchart can be found in Fig. 4.1.

Pizza Making

batch sizeDelay of 1.9 min

Order Taking

pizza sizedough & saucing

final ingredientprimary ingredient

40%

60%

Oven Process

what size

Delivery

Carryout

Unload Oven

dat fileassemble boxes

cook time = 7.5 min

Figure 1: Basic flowchart design of the pizza making process

After a considerable amount of reading, discussing, and planning, the team started handwriting code

(logic) to implement into Arena. The simulation was determined to start when a order is processed; there-

fore, the total time a customer spends on the phone is negligible in the study. Also, the phone ordering

system is assumed to have infinite capacity. At this stage, a discrete distribution was investigated in order to

group the entities arriving into batches. The information given by Miss Sally model is that 64% of the orders

are for one pizza; 31%, two pizzas; and 5%, three pizzas. The built in Arena function DISC was determined

to be a satisfactory method of approaching the batch sizing. This will be further discussed in section 4.2.1.

The varying demand from 20 to 60 pizzas per hour was taken into account at this time. In this study, it

was assumed that each pizza shop to be built will have a general idea of what their demand will be. With

this in mind, the team settled on using exponential interarrival times that will be varied in the data analysis

phase. This decision is based on the fact that the team will attempt to build a model that will recommend

certain configurations to Sally based on her expected demand at a particular store. With demand being varied

for each store, the idea of switch-points was formulated. You may be asking yourself at this time, what

are switch-points? Although detailed descriptions of switch-points will be expanded on further in this

report, the list below will attempt to give a general synopsis of the use of switch-points.

Certain configurations will be recommended to Sally and present her with the most economical choice

5


9/33

for each store that is to be built

The team will develop certain demands at where the configurations would need to be altered by Sally.

These points are defined as switch-points.

Switch-points will not be definitive points at which each shop should be configured. These willsimply be recommendations and many parameters should be taken into account before making a

definite decision.

The pizza making process was then considered, and the team determined to model the pizza making

process in terms of number of workers. As there was no specification of the pizza type to the processing

time, this extraneous information was left out of the model. Each pizza type served by Sallys shops must

go through each of the three make-stations, as there is no pizza that is simple enough to go through only

the first two stations (i.e. no cheese pizza). The one person process would simply consist of one process

module with the processing time set equal to the sum of each of the three pizza making operations. The

team decided to model the two person process with three processes seizing two resources where the three

processes would represent the standard pizza making operations. This will cause both of the makers to rotate

jobs on the make table and complete the next task that needs to be done. This assumption will require the

two workers to be rather flexible (i.e. have the ability to perform any of the pizza making operations).

After completing pizza making, the pizzas then needed to be loaded into the oven. This was to be done

by means of a slide that buffers the area between the make table and the oven [1]. This slide allowed for

pizzas to be loaded into the oven with a load space that varies by oven size and was described as being

modeled to load the pizzas into the oven in 1.9 minutes. For the model to function properly, it was found

that the state of this oven loading process needed to be monitored closely. This was both to ensure that this

space utilization was not exceeded and more importantly, to constrain the flow of pizzas through the pizza

making process if the load space is full.

This interaction between the pizza making process and the oven loading was needed to ensure that only

one pizza was held between any two steps in the pizza making process, and that there were no more pizzas

after the final ingredients process than would fit in the oven load area. Thus, a model was arrived upon

that checks the condition of the process ahead of it to be sure that no entities would be sent on that do not

have room to go to the next step in the process. This involved allowing an infinite queue to build beforethe first process in the model. That queue would not be allowed to release until there were less than two

entities in the process and the queue holding for inspection of the state the process is to follow. Two entities

were allowed ahead of the process to allow for one pizza to be in the queueing area between the processes.

Additionally, one entity will be allowed in the process or sitting finished in the process area, something that

cannot be done in Arena. Therefore, the team allowed a queue of two in an area that is only supposed to have

room for one pizza. The second pizza making process is managed in a similar way with the exception of the

6


10/33

fact that it is preceded by the aforementioned queue with a maximum of two. The queue between the second

and third pizza making stations will be allowed to be of size two for the same reason as the one before it.

However, this queue will not release until both the final pizza making process and the queue following the

final pizza making station are empty. The queue following the pizza making station is the one that will

check for sufficient room to move the pizza to the oven loading area and will be allowed a maximum queueof one in order to imitate the situation where there is a finished pizza sitting in the processing area of the

final station.

Once a pizza finishes the allotted 1.9 minutes in the load area, the space that it occupied will immediately

be released for use of the pizzas to follow and the pizza will begin the 7.5 minute delay for cooking. This

delay will not be capacitated as the oven loading area will control flow into the oven. Upon finishing the

delay through the oven, the pizza is then to be cut and boxed by an unload worker. This resource is also

responsible for assembling boxes in idle time, a task which can be assisted by delivery resources if the

system gets in a bind.

The time to complete the cutting and boxing of the pizzas was given in a rather ambiguous data file

(IIE SM 3.dat) of observations taken by a Co-Op student Sally hired [1]. When the data file was presented,

it was given with the caveat that there may be some bad data in the file. However, when the file was plotted,

the team did not find bad data, but rather two distinctly different distributions as can be clearly seen in Fig.

2. There is a distribution of lower values, Distribution 1, that make up the majority of the data points;

however, there is also a distribution of higher values, Distribution 2, that contain far too many data points

to merely be dismissed as bad data. To further study these distributions, the data was split at several different

points and analyzed with Arenas input analyzer with a split at the value of 5.8 giving the most satisfactory

results. The split data yielded two triangular distributions, both of which had strong fits as can be seen in

Fig. 2.

The conclusion that there were two distributions in the data file rather than a single distribution with some

bad data points left the need for assignment of the reason behind the split in the data. After considerable

deliberation, the team decided to assign Distribution 1 to the times when the unload worker has pizza boxes

preassembled when a pizza exits the oven. Distribution 2 was assigned to times when the worker has to

assemble a box in order to box the pizza (the box was not ready when the pizza was). Therefore, there was a

sense of urgency associated with Distribution 2. With these assumptions made, the team also assumed that

the times represented in the file were in seconds because it was felt that a mean of over three minutes to

cut and box a pizza was absolutely ridiculous. This generated another assumption in that the unload worker

would work much faster when pressured to get a box together than he would while assembling them on idle

time, necessary.

Once the pizzas were boxed, they were assumed to need to wait for the other pizzas that were ordered

7


11/33

0 200 400 600 800 1000 1200 1400 16001

2

3

4

5

6

7

8

9

Time(seconds)

Observation

Distr. 1

Distr. 2Time dependent observations provided by Sally

Figure 2: Graphical representation of the data provided by Sally

Distribution 1

tria(1, 3.06, 6)

square error: 0.000484

Distribution 2

tria(5.48, 7.92, 9)square error: 0.002386

Figure 3: Distributions produced for the data provided by Sally

8


12/33

with them. As soon as the order was assembled, they were to be sent on to the final destination of either

carry-out or delivery. When sent on to carry-out, the processing time of the orders is then complete and all

that remains is to compare the makespan of the order to the 35 minutes allowed for a satisfied customer.

Orders sent out for delivery must wait for a free delivery resource and the processing time of their delivery

before the time in system of the order, and thus the satisfaction of the customer can be calculated. However,the delivery system cannot be terminated at this point because the delivery resource must be returned to the

shop before it can be used for another order. This requires another delay in which the resource is held for

the time it took to get to the delivery destination.

4.2 MODEL DEVELOPMENT

4.2.1 Create Order Submodel

For the creation module used in the Create Order submodel, the first goal was to have pizzas of the same

order arrive at the exact same time. In order to accomplish this, a discrete distribution, DISC(0.64, 1,

.95, 2, 1, 3), is entered in the entities per arrival section of the create module. These arrivals were created

according to an exponential distribution with a mean of the variable IAT (inter arrival time). This was

done to allow the arrival rates to be changed in the process analyzer without the need to update the p-file.

This will in theory develop a robust model that can be analyzed without brute-force methodologies.

The logic for the assignment of the order number was then implemented in the model. This logic follows

a few modules used for model termination which will be discussed in section 4.2.6. The goal is to ensure that

all entities that arrive at the same time be assigned the same order number. This methodology will be utilized

later for batching of pizzas. This process begins by assigning each attribute an arrival time of TNOW as

it enters the system. The pizza entities are then sent through a decide module that look at whether the

entitys arrival time, denoted by an attribute ArriveTime, equal a variable called VariableArrivalTime.

This variable is used to determine if the entities arrival times are equal to each other and in the event that

they do not, the entity is sent through the false branch of the decide module, where the variable is updated

to the new arrival time. The order number variable, denoted as VariableOrderNumber, is also incremented

at this time. In the event that an entity goes through the true branch of the decide module, the entity then

enters an assign module that increments a variable called VariableBatchSize that is designed to count how

many entities are in the current batch. This will also be used later in the batching process described in

section 4.2.4. An entity that goes through the false branch will result in this variable being reset to one.

The true and false branches of the above decide module reconverged on an assign module that assigns

the order number variable to an attribute OrderNumber on each entity. The entities then enter a process

module with a delay of 0.00001 seconds, the shortest of an amount of processing time that Arena recognizes

(note: more about this process can be found in section 4.3). This process is in the model in order to allow the

9


13/33

other entities that arrived at the same time to enter the decide module process described above, prior to any

of the entities being assigned an order size. Once any entities that arrived at the same time have entered this

module, they will execute the respective 0.0001 processing time so quickly that the possibility of another

arrival coming is insignificant. VariableBatchSize is then assigned to an attribute called BatchSize for

each entity.

The entities then proceed to another decide block that goes through a n-way decide by chance which

is split up with 32% going through one branch, 56% going through a second branch, and the remaining

12% going through the false branch. These branches proceed to assignments for large, medium, and small

pizzas respectively. In these assign modules; the entities are assigned attributes for the processing times for

the dough and sauce process, the primary ingredients process, the final ingredients process, and the area it

will use in the oven process. The area corresponding to the small, medium, and large ovens is 250, 175,

and 115 square inches respectively. These processing times,given in minutes and based on sizes of pizzas,

can be found in Table 2 and follow triangular distributions [1]. After these assignments, entities leave thesubmodel and continue on to the pizza making submodel.

Task Large Medium Small

Dough & saucing 0.5, 0.7, 0.8 0.4, 0.6, 0.8 0.3, 0.5, 0.7

Primary ingredients 0.6, 0.8, 1.0 0.5, 0.7, 0.9 0.4, 0.5, 0.6

Final ingredients 0.5, 0.6, 0.7 0.4, 0.5, 0.6 0.3, 0.4, 0.5

Table 2: Processing times based on pizza size [1]

4.2.2 Pizza Making Submodel

When the order arrives to the pizza making section of the model, each pizza is made individually. As

previously noted, there are three different types of pizza making processes: one worker, two workers, and

three workers. Table 13, located in section 6.1 determines how many pizza makers are needed. There are

four different models included with this report. Three of the models have one type of pizza making process

(one worker, two workers, and three workers). The fourth model has all three of these processes. This model

has all the pizza making submodels included; therefore, a user can choose how many pizza makers he or

she would like to use through the use of a route module at the end of the Create Order submodel. There

is currently no way for this model to automatically determine which pizza making process to use, however,

this implementation method is currently being investigated.

In each model and as noted above, the pizza making processes begin with a route from the Create

Order submodel (Route name is Go to Pizza Maker) to a station in the specified pizza making submodel

(One Pizza Maker, Pizza Making 2 Guys, or Pizza Making 3 Guys). The stations are named Pizza

Maker 1, Pizza Maker 2, and Pizza Maker 3 respectively. There is no delay in this process. Each process

10


14/33

has three stations on a standard make-table. The three stations are dough and sauce, primary ingredients,

and final ingredients. The pizza then waits to enter the loading area of the oven. The team used a holding

block labeled Wait for Oven 1 (Wait for Oven 2 or Wait for Oven 3 if in the second or third submodel,

respectively) to determine when there is enough room for the loading area of the oven. This hold continually

scans a variable named LoadSpaceRemaining. For more information about how this variable works in thecurrent design and how the loading area is developed in our model, refer to section 4.2.3.

The One Pizza Maker submodel is rather simple compared to the other two submodels. When a pizza

is ready to be made, it first enters a hold module named Check Final Hold Before Release 1. This hold

module continually scans the total work in process (WIP) in the process named Assemble Pizza and the

queue in a subsequent hold module named Wait for Oven 1. The total WIP and the queue in the Oven

hold, when added together, must be less than two before the pizza is allowed to enter the Assemble Pizza

process.

The associated equation for the Check Final Hold Before Release 1 module is represented in Eqn. 1.

ScanCondition = AssemblePizza.WIP + NQ(WaitforOven1.queue) < 2 (1)

A value of two was chosen because there can be a pizza waiting to enter the loading area of the oven (acts

as if it is sitting in the third make station), and the one worker may work on another pizza. If this is the case,

when the worker reaches the third make station to work on final ingredients and the pizza already completed

has not yet entered the load area, an assumption has been made that the worker will place the finished pizza

in the buffer between stations two and three. Consequently, the worker is permitted to continue with thefinal ingredients on the unfinished pizza. If the worker is finished with the second pizza and neither pizza

has yet to enter the oven, the worker becomes starved until one of the pizzas has entered the load area. At

this point, the second pizza enters the Wait for Oven 1 hold module. During this entire process, the pizzas

that are being being made seize a single resource, WorkerOne and only one pizza can be made at a time.

The expression for the processing time (in minutes) adds the three attributes of the pizza (assigned in the

Create Order Submodel) as denoted in Eqn. 2.

ProcessingTime = DoughSaucePT+ PrimaryPT + FinalPT (2)

Once completed, the pizza enters the hold module labeled Wait for Oven 1 before it enters the loading

area.

For the Pizza Making 2 Guys, once a pizza arrives, it enters a hold module named Check Dough

2. This hold continually scans the next immediate process named Dough Sauce Two Workers and the

11


15/33

succeeding hold named Check Primary Hold Before Release 2. In this case, it scans the total WIP for the

first make station and number in queue of the hold module to be less than two. It also scans to make sure

that only one worker is working on a single pizza at any time. This logic is implemented in the model using

the condition of number out of the Dough Sauce Two Workers module subtracted from the number in of

that module must be less than one.

A value of two was chosen because the hold module will be used as a queue and a buffer. The hold

module can in theory hold the pizza that is waiting in the queue of the next process (second make station)

labeled Primary Ingredients Two Workers, and hold the pizza at the first make station. Depending on

the simulation time, this pizza sometimes cant be moved because of the pizza in the queue ahead of it.

When this is the case, the resource in the Dough Sauce Two Workers process will not be allowed to be

seized, due to the hold Check Dough 2. The expression for the process time (in minutes) at Dough Sauce

Two Workers is the attribute DoughSaucePT, which was assigned in the Create Order submodel. This

process is of seize-delay-release and only one pizza can seize a single worker.

After a pizza leaves the Dough Sauce Two Workers process, the pizza enters the hold module called

Check Primary Hold Before Release 2. This hold continually scans the next immediate process named

Primary Ingredients Two Workers and the succeeding hold named Check Final Hold Before Release 2.

The scanning condition works the same as before, in that the total WIP of the process and the queue of

the hold must be less than two. Also, the number in minus number out of the Primary Ingredients Two

Workers module must be less than one.

The expression for the process time (in minutes) at Primary Ingredients Two Workers module is the

attribute PrimaryPT, which was assigned in the Create Order submodel. The process is of seize-delay-

release and only one pizza can seize a single worker.

When the pizza leaves the Primary Ingredients Two Workers process, the pizza enters the hold module

Check Final Hold Before Release 2. This hold continually scans the next immediate process named Final

Ingredients Two Workers and the succeeding hold named Wait for Oven 2. This scanning condition works

the same as before, in that the total WIP of the process and the queue of the hold must be less than two.

Additionally, the number in minus number out of the Final Ingredients Two Workers must be less than

one.

The expression for the process time (in minutes) is the attribute FinalPT, which was assigned in the

Create Order submodel. The process is of seize-delay-release and only one pizza can seize a single worker.

The pizza leaves the Final Ingredients Two Workers process and enters the hold module Wait for

Oven 2 until it can enter the loading area. This hold process is explained in section 4.2.4. After the hold,

the pizza enters a route module named Go to Load Oven 2 where it arrives at station Load Oven.

12


16/33

The team used a set for the three processes in this Pizza Making 2 Guys submodel. This set, called

Workers 1 and 2, consists of the two resources, WorkerOne and WorkerTwo. Only one pizza seizes

each resource. The selection rule is of preferred order.

The Pizza Making 2 Guys and Pizza Making 3 Guys submodels are very similar in design. The holds

and processes are the exact same, except the names and holding queues change from Two to Three and

2 to 3 respectively. The main difference in the Pizza Making 3 Guys is at each make station (each

process), there is a designated resource. Dough Sauce Three Workers seizes the resource WorkerOne,

Primary Ingredients Three Workers seizes WorkerTwo, and Final Ingredients Three Workers seizes

WorkerThree.

4.2.3 Oven Loading Submodel

The team used a holding block labeled Wait for Oven 1 (Wait for Oven 2 or Wait for Oven 3 if in thesecond and third submodels, respectively) to determine when there is enough room for the loading area of

the oven. This hold continually scans a variable named LoadSpaceRemaining. The scanning condition is

PizzaArea LoadSpaceRemaining, simply stating that the size of the pizza must be less than or equal to

the amount of space still remaining in the load area. This variable must be initialized by the user according

to what series oven he or she wants to use. The model is being updated to include a decision based system

that will decide what size oven to use based on a given peak demand. The LoadSpaceRemaining value

is 435, 520, or 605, based on Series I, II, and III respectively. The user must also input the capacity of the

resource LoadingResource to this exact same value. The variable LoadSpaceRemaining updates itself

every time a pizza enters the loading area or enters the oven (which is the same as leaving the loading area).

Once a pizza leaves the Wait for Oven 1 (Wait for Oven 2 or Wait for Oven 3 if in the second or

third submodels, respectively) hold, it enters a route block named Go to Oven 1 (Go to Oven 2 or Go

to Oven 3 if in the second or third submodels, respectively) and arrives at the station, Load Oven.

Once the pizza arrives at the Load Oven station, the variable LoadSpaceRemaining decrements

itself by PizzaArea, the attribute value of the size of the pizza assigned in the Create Order submodel.

This is completed with the use of an assign module labeled, Load Space Remain Decrement by Size. Once

the variable decrements itself from the assign module, the pizza enters a seize-delay-release process labeled,

Loading the Oven. In this process the pizza seizes the resource LoadingResource with a quantity equal

to PizzaArea (attribute of the size of the pizza). The delay type is a constant 1.9 minutes. Once the pizza

leaves the process, it enters another assign module which increments the variable LoadSpaceRemaining

by the amount of the PizzaArea that just left the loading area. From here, the pizza enters a route block

named Go to Oven and arrives at a station named Enter Oven.

13


17/33

4.2.4 Oven Unloading Submodel

After arriving at the Enter Oven module, the pizza leaves and enters a seize-delay-release process named,

Oven Conveyor Process seizing a resource named Conveyor Oven with a quantity equal to the Piz-

zaArea. This has an infinite capacity with a constant processing time of 7.5 minutes. This module is thereto create the delay that is given for the time that the pizzas take in the oven. Once through this oven delay,

the entities go through a decide module that checks if there are boxes already made for them to be boxed. In

the case that there are boxes, the false branch in the decide module, they are sent through a process module

using the short distribution derived from the dat file provided by Sally. This process is TRIA(1, 3.06, 6)

seconds and is in place to simulate the time it takes to cut and box a pizza. The processing time was derived

from determining that the dat file is of two distributions as defined in section 4.1. The entities then proceed

through an assign module that decrements the variable for number of boxes on hand, NumberOfAssem-

bledBoxes. In the case that there are not any boxes on hand, the entities go through the true branch of the

decide module and are routed through a process module that uses the longer distribution from the dat file,

TRIA(5.48, 7.92, 9). This distribution represents the time it takes the unload worker to not only get the

pizza cut and into the box, but the time it takes the worker to put together the box while being hustled by the

fact that the pizza needs to get out the door. If the worker is in a hurry, the assign module that decrements

NumberOfAssembledBoxes is bypassed.

The boxes to be used for this process are created in a small auxiliary model that uses its own separate set

of entities, but is still inside of the Oven Unloading submodel. The create module in this section creates

only as many entities as there are resources for unloading and delivery. These are then used to trigger the

manufacture of more boxes as needed. Following the creation of the box making entities, BoxSignal,

the entities immediately enter a hold that tests whether the maximum number of boxes to be held, 30, is

met. If this is not the case, and boxes to fill this up have not already been requested by an earlier release, a

BoxSignal entity is released. From there, the entity proceeds to a decide module to test whether boxes are

in short supply and needing to be made by both unload workers and delivery guys. In the case that the supply

is greater than five boxes, the entity travels through the false branch which has a process module 12 second

delay and is set to seize only the unload worker. In the case that the supply is short, the entity travels the

true branch with a process whose only difference is that it seizes both the unload and the delivery resources.

The two paths join back together at an assign module that increments NumberOfAssembledBoxes. The

entities in this system are then recycled back into the hold module. The processes in the box making model

are given a low priority so that if the resources they seize are demanded elsewhere, they will be seized for

those processes first (especially the unload worker).

Once the pizzas have been boxed, they are batched by order number. This is done using a batch module

that creates batches using the attributes of BatchSize and OrderNumber assigned in the Create Order

14


18/33

submodel. The logic used in this module is that it holds entities of each OrderNumber until BatchSize

entities are gathered. These entities are then released as a batch to a two-way by condition decide module

that sends 40% of entities received to be delivered and the other 60% to be carry-out orders. The entities that

are to go to the delivery process are then assigned an attribute, DeliveryTime, which governs how long it

will take the pizza to be delivered with a distribution of TRIA(3, 5, 12). The entities are then routed to theDelivery or Carryout submodel.

4.2.5 Delivery or Carry-out Submodel

When a carry-out order enters this submodel, it arrives to an assign module, where an attribute TotalOrder-

Time is assigned, which is equal to TNOW - ArrivalTime where ArrivalTime is the attribute assigned

in the Create Order submodel when the order was originally called in and TNOW is the current time

in the system. From here, the order enters a decide module Was Carryout on Time? This decide module

is a two-way by condition that decides if TotalOrderTime 35. If true, the order enters a record mod-

ule, Record Carryout Satisfied Customers, where a counter is incremented by a value of one to a variable

named Record Satisfied Carryout Customers. If the decide module proves to be false, then the order enters

a record module, Record Carryout Unsatisfied Customers, where a counter is incremented by a value of

one to a variable named Record Unsatisfied Carryout Customers. Independent of the previous decision,

the order then enters a record module, Record TIS for Carryout where a tally keeps track of the time in

system spent for the order based on its ArrivalTime. The next step is to decrement the variable NumberIn-

System by a value of one, which is accomplished in the assign module, Decrement NIS 1. The order is

then disposed.

When a delivery order comes through the station, it arrives to a seize-delay process named, Deliver the

Pizza. The order seizes a single resource, which is named DeliveryBoys. The user will need to decide the

capacity of this resource. Once again, a model is currently under development that will make this decision

based on a given peak demand. Currently, to determine capacity of delivery drivers, the user will need to

look at the results in Table 1. The delivery drivers are based on the peak demand. After determining how

many delivery drivers are needed, the user will have to input this value under capacity in the resource

module. The processing time (in minutes) for the order is an expression DeliveryTime, which was assigned

as an attribute to the order. The order will sit in the queue of the process until a resource is available, whichis based on the specified capacity. The order stays in the process during the delay time (DeliveryTime)

and afterwards the order enters an assign module that determines the attribute TotalOrderTime, which is

equal to TNOW - ArrivalTime (the same expression as the carry-out system).

The order then goes through a decide block that asks if the order was delivered on time. Here, a two-way

by condition states if TotalOrderTime 45. If true, the order enters a record module, Record Delivery

15


19/33

Satisfied Customers, where a counter is incremented by a value of one to a variable named, Record Satis-

fied Delivery Customers. If the decide module proves to be false, the order enters a record module, Record

Delivery Unsatisfied Customers, where a counter is incremented by a value of one to a variable named,

Record Unsatisfied Delivery Customers. The resource is still being seized during this process because the

delivery worker must to drive back to the pizza shop. The team took care of the return trip by then havingthe order enter a delay process named Drive Back to Pizza Shop. Here the delay is the expression Deliv-

eryTime, which is the attribute of the order. The team did this so that the time to drive back to the pizza

shop was the same as the time to drive to the customers location. Once the delay time has finished, the

delivery driver acts as if he is back to the pizza shop and is then released from the order. The next step is to

decrement the variable NumberInSystem by a value of one, which is accomplished in the assign module

Decrement NIS 2. The order is then disposed.

4.2.6 Terminating Condition

A pizza shop such as Sallys closes after a certain time of operation. However, even after the orders stop

being accepted they must all still be processed before the shop can close. A situation like this requires that

the model be a terminating model that clears the system prior to ending a replication. In order to execute

this, modules were inserted into both the Create Order and the Delivery or Carryout submodels and the

conditions of the termination were added to the replication parameters of the run setup.

In the Create Order submodel, there is a decide module which sends entities through the true path

and therefore into the pizza making system for the first one hundred eighty minutes. After this point, it

routes arriving entities directly to a dispose module that is separate from the rest of the model. Directly

after the true branch (TNOW < 180 minutes) there is an assign module that increments a variable for the

number of pizza entities in the system, denoted as NumberInSystem. The NumberInSystem variable is

incremented only after the false branch of the following decide module that is used to create order numbers

because the entities leave the system as a batch that is controlled through this logic. This variable is then

decremented in an assign module that is the last module through which the entities travel before going the

dispose modules at the termination of either the delivery or carry-out process in the Delivery or Carryout

submodel.

The above statistic is tracked in order to facilitate the terminating conditions in the run setup. This con-

dition is that both the time be greater than or equal to 180 minutes and that there are no more entities in

the system past the incrementing of the number in system just mentioned. This is entered in the termination

conditions portion of the replication parameters as TNOW 180 && NumberInSystem = = 0. The repli-

cation length was set to ten hours as this would give time to run the orders to completion and not impede the

function of the terminating condition clearing the system.

16


20/33

4.3 VERIFICATION & VALIDATION

Before obtaining results for the analysis phase of the study, a set of verification processes were completed.

The model was broken up into segments to be verified in order to simplify verification of the entire model.

This was completed as verification of the entire model would be problematic and extremely difficult. Thissection presents some finding of the verification process.

In order to verify the Create Order submodel, the model was reconfigured to include several new

statistics. These statistics were the percentage of orders of size one, two and three, as well as the number of

small, medium, and large pizzas created. This model, Verify Order Creation.doe, also includes the batch-

ing process that is contained in the oven unloading submodel in order to verify that process and complete the

verification of the percentage of order sizes. The model was terminated with a dispose module rather than

sending the entities to the remainder of the process and was run with a terminating condition of three hours

rather than clearing the system of entities (done in the original model); however, since there is no significant

delay in the system, the verification model always terminates empty.

The purpose of this model is to compare the assignments of batch size, and the assignments of pizza size

in the model to the ratios required in the description of Sallys pizza shop. To this end, the above described

model was run for ten thousand replications and the statistics gathered from these runs were compared to

the actual desired values. As would be expected from a correctly functioning model, they did in fact line up

with desired distributions in the model.

Another verification procedure that was accomplished for the Create Order submodel was finding the

slowest processing time that one can assign to a basic seize-delay-release process. A single server queuemodel was generated to test this idealogy. After instigation, it was found that the slowest processing time

that Arena can use for delay in a process module is 0.00001 seconds. If one tries to enter any time less than

0.00001 seconds, Arena will give an error report.

Considerations were made to verify the design that the system has a maximum of one pizza in the queue

between pizza makers. If the worker at a particular station is finished working on a pizza and there is a pizza

currently waiting for the next station, the worker could not release that pizza into the queue; therefore, the

pizza must remain on the table and the worker is not allowed to begin his process on the next pizza. Fig. 4

is a screen shot of the animated model that proved the model is designed correctly.

The blue ball labeled as #1 shows that there is a pizza waiting to be loaded into the oven. The model

is acting as if the pizza were still on the third make table. It is assumed that there is no buffer area to place

the pizza before the loading area. If the pizza cant be placed in the loading area, then it remains on the third

make table and the third worker is unable to work on another pizza until it enters the loading area. As a

result, the third worker is starved, as designated with a value of zero for WIP in the Final Ingredients Two

17


21/33

Workers.

The hold module before this process, labeled Check Final Hold Before Release 2, scans for the Oven

hold to be empty before allowing the next pizza to enter the Final Ingredients Two Workers process. The

blue ball labeled #2 acts like the pizza in the queue between the second and third work stations. The blue

ball labeled #3 acts like the pizza at the second station that cant be moved. As the animated model shows,

to be correct as the second station, Primary Ingredients Two Workers has a total WIP of zero. Even though

the ball (pizza) is not seizing the resource, the hold modules make this work correctly. The worker at the

second station is unable to work because he/she has a pizza on their station (#3) and cant move it because

#2 is in the queue. Consequently, #2 is waiting to be processed at station three.

The hold module labeled Check Primary Hold Before Release 2 works the same as the hold in the

previous paragraph. The blue ball labeled #4 acts like the pizza waiting in the queue between stations one

and two. It can not seize the resource at Primary Ingredients Two Workers because the pizza labeled #3

is on the make table. The blue ball labeled #5 acts like the pizza that is sitting on the make table at station

one, completed, but it can not be released as a result of #4 sitting in the queue between stations one and

two. This is why the resource at Dough Sauce Two Workers can not be seized and the total WIP at this

process is zero.

The Check Dough hold module scans the Dough Sauce Two Workers total WIP and the Check

Primary Hold Before Release Two hold to make sure that a pizza does not seize the resource at Dough

Sauce Two Workers when there is a pizza in the queue between stations one and two and another pizza

on the make table (whether it is being processed or waiting to enter the queue at the next station). In more

simplistic terms, this acts like the queue of the Dough Sauce Two Workers. For example, the blue ball

labeled #6 is like the entity in the queue, waiting to begin dough and saucing.

The SIMAN output report in Arena was utilized to prove that the maximum number in queue at the

holds was in fact two, and the maximum number in queue at the processes was one. In the current design,

the only reason there will be an entity in queue at a process at any given time is if the pizza enters a process

and there is no resource to be seized. For example, in the two-pizza maker process, a pizza may enter the

second station, but the two workers may be at stations one and three. Therefore it is placed in a queue. At

no time will there be a queue of one in the process and a queue of two at the prior hold. The other scenario

(when the processes can have a queue of one), is when there is nothing in the queue ahead of the station.This is more common in the three person model. The hold module, when this instance occurs, would have

a capacity of one (acting as the pizza at the make-table in the prior process waiting to join the queue).

After checking the run controller, analyzing the results of the queues, and most importantly, stepping

through the model (as displayed with the screenshot below), the team is confident that the model is a correct

representation of Sallys shop.

18


22/33

#1#3

#6

#2

#4#5

Figure 4: Screenshot used for verification of the pizza making submodel (2 & 3 workers)

The team verified the delivery and carry-out portions of the model were correct by stepping through

the model and making sure that it worked as expected. The screenshot found in Fig. 5 was used in the

verification process and will be described below.

Figure 5: Screenshot used for verification of the delivery submodel

The two important parts from the screenshot to view are the seize-delay process module, Deliver the

Pizza and the delay module, Drive Back to Pizza Shop (both seize resource: DeliveryBoys). In this

example, the team set the capacity of DeliveryBoys to four. In Fig. 5, the Deliver the Pizza module has

a total WIP of four and the Drive Back to Pizza Shop has a total WIP of two. These two modules added

19


23/33

together is six, but there are two orders in the queue at the Deliver the Pizza module. This appeals to ones

intuition as there are six minus two, or four, delivery drivers available at a single time. An assumption is also

made that the delivery drivers do not go on a break over the time the shop is open. Once the order enters the

Release Delivery Guy module, an order in the queue at Deliver the Pizza will then immediately seize

the resource. This proves that the delivery process works as designed.

The method used to verify that the percent satisfaction of the customers is correct was to design a

separate model, Delivery.doe. Using a create module, the team first recorded the arrival time at an assign

module and then sent the order through a process module. This process acts like the entire system of our

actual model, as it possesses a random processing time. The order then enters an arrival module, where

it is assigned a delivery time. The order then enters a process that acts like the delivery itself. If the

resource is not available, it sits in the queue and waits for the resource to become available. The process

time is equal to the delivery time that the order was assigned. Once the order completes this process, it is

assigned a TotalOrderTime, which is equal to TNOW - ArrivalTime. The decide block decides if theTotalOrderTime is less than or equal to 45 minutes. If true, the order increments the amount of satisfied

customers by a value of one. Subsequentl, if false, the order increments the amount of unsatisfied customers

by a value of one. The team ran this model and stepped through it with the run controller. This was

performed manually by running the model example. Tables 3 & 4 show the results of four orders moving

through the system.

Model Order 1 Order 2 Order 3 Order 4

Arrival Time 0 20.768 24.379 31.873

Ending of Process 19.239 38.331 60.623 78.188

Assigned Delivery Time 5.066 6.658 8.841 8.636Ending Order Time 24.305 44.988 69.464 86.823

Total Order Time 24.305 24.219 45.084 59.951

Customer Satisfied Yes Yes No No

Table 3: Results given from the delivery verification model

Calculated Order 1 Order 2 Order 3 Order 4

Arrival Time 0 20.769 24.379 31.873

Time in Process 19.239 17.562 36.243 46.315

Assigned Delivery Time 5.066 6.658 8.841 8.636

Total Order Time 24.305 24.219 45.084 54.951Customer Satisfied Yes Yes No No

Table 4: Results calculated from the delivery verification model

Take note that the numbers under Model are the values given in the model and the numbers under

Calculations are calculations made from observing the model. The value that verifies the logic is that the

calculated Total Order Time equals the Total Order Time given by the model. The Total Order Time for the

20


24/33

Model is the attribute value given by Arena while Calculations Total Order Time = Time in Process +

Delivery Time. Time in Process is Arrival Time subtracted from Ending of Process (from Model). Also

notable is that the counters are equal. The counter values increment for each order based on whether or

not the customer was satisfied or not. The SIMAN Report verifies that the number of customers satisfied is

properly calculated as the value in the SIMAN Report equals two. Note that if the user adds the total numberof satisfied customers (the Yes columns) this equals two as well.

The team used the exact same method for carry-out process using a model named, Carryout.doe. A

second verification model was created that is identical to the delivery verification model with the exception

of the assign block that assigns a delivery time and the delivery process. The team stepped through the run

controller and the results were the same as for delivery, each Total Order Time were equivalent.

In order to verify the model terminating conditions are operating correctly, the portions of the model that

control this were placed in a separate model. This model contains a create module, where the distribution

for entities per arrival has been replaced with just a single entity per arrival. It also contains the decide

module used in the model termination with its accompanying assign modules to increment and decrement

the number in system (NIS) and dispose modules at the false branch and the end of the system. The model

is set with an exponential arrival rate of one entity per minute and contains a single process between the

assign module that increments the NIS and the assign module that decrements NIS, with a processing time

of 0.8 minutes, also exponentially distributed in order to create a queue, but not a particularly long one.

This process can easily be modeled with M/M/1 queueing analysis that predicts the systems steady state

performance [2]. The purpose to the short queue mentioned above is to allow the process to come to steady

state before the termination of the model and as such, allow these formulas to be useful. With the system

in a steady state at termination, the average WIP at in the system can be calculated. With the average WIP,

and the average processing time, the time that the system will have to run after termination can be easily

calculated as average WIP times the average processing time. When this calculation was performed, the

time to completion after termination was calculated to be 3.2 minutes, which fell within the 95% half width

of the confidence interval for the average time the system ran after close when the model was run for 1,000

replications; therefore, verifying the termination model.

In order to properly validate the model given the time and resource constraints of the project, the team

used a hybrid design of experiments to analyze the results of the model. One would expect the percentsatisfaction and each input parameter to have a positive correlation. The team put this theory to test in

developing an experiment to start with a base model and increment input parameters. The results from

this experiment can be found in Table 5.

The results in the table describe how the customer satisfaction will increase when adding additional

pizza makers and delivery drivers, or increasing the oven size. The first step was to increment the number

21


25/33

Customers Number of Number of Expected

per Pizza Delivery Oven Satisfaction

Hour Makers Workers Size Level

45 2 3 435 64.92 %

45 2 4 435 77.52 %

45 2 3 520 74.92 %45 2 4 520 90.28 %

45 2 3 605 75.56 %

45 2 4 605 90.86 %

45 3 3 435 65.62 %

45 3 4 435 78.46 %

45 3 3 520 75.91 %

45 3 4 520 91.99 %

45 3 3 605 78.86 %

45 3 4 605 95.34 %

Table 5: Statistics gathered for use in validation

of delivery drivers from the base configuration found in row one of Table 5. Incrementing the number of

delivery drivers from three to four and keeping all other parameters at the same level, the percent satisfaction

increased by 12.6%. This demonstrates that the model is performing as expected and that increasing delivery

drivers can enhance the performance of the entire system a great deal. Additionally, it should be noted

that increasing the oven size from 435 to 520 significantly affected systems performance. Note that this

representation can be found in row three, where the base configuration is used with a 520 size oven is used

in place of the 435 size oven. The last input parameter to evaluate is the change in pizza makers. Again,

looking at changing the base configuration to use three pizza makers instead of two, this also improved

the percent of customers satisfied. It should be noted that for the given peak demand rate of 45 customers

per hour, the number of pizza makers only increases the performance of the system slightly. However, as

the peak demand rate increases, the number of pizza makers used in the system is more significant.

In a real-world study, Sally would implement the configurations in pizza shops in her expansion pro-

gram. Then, observations would be made to validate that the system was performing as expected. However,

for this pilot study, the team was limited to simply gathering statistics such as the ones in Table 5 to ensure

that the model performed as expected.

5 APPENDIX II - Model Analysis

5.1 OUTPUT ANALYSIS

Upon completion of the model development and verification, statistical analysis was performed to evaluate

the performance of the pizza shop. Preliminary investigations were conducted to gain insight on how the

22


26/33

model (the pizza shop) would react when input parameters were altered. As previously mentioned, the input

variables for this study were determined to be the arrival rate of customers to the store, the number of pizza

makers at the make-table, the number of delivery drivers, and the size (series) of the even. After these initial

experiments, more detailed studies were executed in order to detect the most profitable configurations for

each pizza shop to be opened. The performance metric analyzed was the customer satisfaction level, asSally said this was the primary objective of the study. She stated that she would like to achieve a customer

satisfaction level between 90 and 95%. The calculation of percent satisfied customers is found in Eqn. 3.

percent satisf ied = {

satisfied customers

total customers} 100 (3)

The team first decided to run all possible scenarios that could produce 90% customer satisfaction for 10

replications each. While first running ten replications of the model, the team found a number of configura-

tions that produced customer satisfaction levels greater than 70%. During the testing phase, any configura-

tion that yielded a customer satisfaction greater than 70% was recorded. For each even customer arrival rate

between 20 and 60 (i.e. 20, 22, 24,..., 60), therefore, 252 scenarios were tested. These scenarios included

one, two, and three pizza makers, two through five delivery drivers, and each series oven. Including all

possible combinations made the total number of configurations tested equal to 756. All configurations that

would produce at least 70% customer satisfaction were considered for the next phase of the output analysis.

The number 70% was chosen as the team felt that there was enough variability in running ten replications

that any value over 70% should be considered. Although the half-width of the 95% confidence interval (CI)

on the mean of percent satisfaction was consistently between 5 and 10% when running 10 replications, the

team felt like it was necessary to include all values within 20% of the target. After computing a number of

99% CIs when the average percent satisfaction is above 65%, the half-width of the 99% CI is consistently

less than 20%. Therefore, the team felt as if all configurations that produced at the least 70% should be

included for further analysis. The team felt that simply running ten replications was not enough to rule out

any configurations where 90% customer satisfaction fell within the half-width of the 99% CI.

It should be noted that the team added configurations including six delivery workers for the greatest

arrival rate (60 customers per hour) as it was found that five delivery workers would not be acceptable for

this demand. This added two more configurations to be tested with ten replications, as the number of pizza

makers at this demand rate must be three and the series one oven could not handle this capacity. This would

include all customer satisfaction levels of 70% or greater for this demand rate. Seven delivery workers

were not considered at this time as the configuration for six delivery workers and the Series III oven gave a

value of 93.2% customer satisfaction. If this value were to drop below 90% satisfaction after running more

replications, seven delivery workers would be considered.

After obtaining all configurations that produced a customer satisfaction of 70% or greater when running

23


27/33

ten replications, each of these configurations were run in the process analyzer for 100 replications each.

There were 203 of the 758 original configurations that fell within this range. Note that all customer arrival

rates must be changed to inter-arrival times to be used in Arenas process analyzer. Additionally, a con-

siderable amount of time was used for the debugging process in Arenas process analyzer as the team had

defined the response statistic as % Satisfied. Apparently, the process analyzer does not accept the % signas a valid assignment for a statistic. Therefore, the statistic of interest was changed to Percent Satisfied.

The team also found that data processing was much more rapid in Arena by simply asking for the SIMAN

report and unchecking unwanted results in the Project Parameters tab of the Run Setup. After obtaining

the results in the process analyzer, a series of decision making processes were completed to ensure that the

team made full use of time. First, a series of financial analysis was completed to determine the price of each

configuration. The prices of each input parameter can be found in Table 6. The capital price of the oven

was assumed to have a five-year conventional payback period [3]. In order to make the price of the oven

comparable to the hourly rates associated with the pizza makers, unload worker, and delivery drivers, the

hourly rates and the conventional payback period were converted into cost per day. This would enable the

team to analyze each configuration by the cost per day of operating at that specified level. A 360 day year

was assumed in this expense analysis to include holidays. Each of the parameters, excluding the price of the

oven, were analyzed similar to Eqn. 4.

$7.15/hr 3hrs 6workers = $128.70 (4)

Delivery Drivers Daily Cost Pizza Maker Daily Cost

1 $21.45 1 $18.452 $42.90 2 $36.90

3 $64.35 3 $55.35

4 $85.80

5 $107.25

6 $128.70 Oven Type Daily Cost (5 yrs)

Series I

Unload Worker $17.70 Series II $19.34

Series III $36.11

Table 6: Daily cost of each input parameter

The team utilized Microsoft Excel to organize and view the analysis from the Process Analyzer more

efficiently. After copying the results for the first 100 replications into excel, the data was sorted to determine

which scenarios produced a customer satisfaction level that was substantial enough to be considered for

further analysis.

Using these values from Table 6, the cost of each scenario was computed. The VLOOKUP function

was utilized in excel to efficiently search for the amount of pizza workers, delivery guys, and oven size to

24


28/33

determine the daily cost. For example, for a peak demand of 58 customers per hour (3 pizza makers, 6

delivery drivers, and Series III oven), it looks up the values and computes the daily cost shown in Eqn. 5.

55.35 + 128.70 + 36.11 + 17.70 = $237.86 (5)

Please refer to Table 7 for the following scenario. Two different configurations produced a peak demand

of 58 customers per hour. Therefore, the daily cost is used to determine which configuration is best for each

demand. Note that each peak demand has more than one scenario to consider except for the peak demand

of 60 customers per hour.

Peak Pizza Delivery Oven Percent Daily

Demand IAT Makers Drivers Type Satisfied Cost

60 1 3 6 Series III 94.19 % $237.86

58 1.0345 3 6 Series III 98.28 % $237.86

58 1.0345 3 5 Series III 93.69 % $216.41

Table 7: Example of two configurations for one peak demand

Using the best (cheapest) scenario, the team was able to determine which scenarios to run for the odd

peak demands (59, 57, ..., 21 customers per hour). This interpolating process was done by taking the scenario

of the next event and previous event to see which was cheaper. Note that if the two scenarios were of the

same configuration, only one was used. This interpolation method was used so that 756 replications would

not need to be run for each of the odd scenarios, saving time so that other data analysis can be completed.

For example (see Table 7), for a demand of 59 customers, the team used the scenario of a demand of 60

and the scenario of a demand of 58 customers, and recorded both of these into the process analyzer. Each

scenario was run for 100 replications using 59 as the peak demand rate. If both of the configurations were

90% or greater, the cheaper version was chosen ($216.41 is cheaper than $237.86, therefore, choose the

second option).



59 1.017 3 6 Series III 97.19 % $237.86

59 1.017 3 5 Series III 91.56 % $216.41

Table 8: Example of choosing cheaper scenario

After obtaining the cheapest scenario for each (integer) peak demand rate for 100 replications, a switch-

points were defined. Please see Table 9 for an example of how the switch-points are defined.

Because a demand of 46 customers per hour has a different scenario than 45 customers, these two

are considered switch-points. The demand for 45 has the same recommended scenario for 44 and 43

customers; therefore, we know that a demand of 44 and 43 will be covered by the demand of 45. The next

25


29/33



46 1.3043 3 4 Series II 90.70 % $178.29

45 1.3333 2 4 Series II 91.79 % $159.84

44 1.3636 2 4 Series II 93.08 % $159.84

43 1.3954 2 4 Series II 94.32 % $159.84

42 1.4286 3 4 Series I 90.86 % $158.85

41 1.4634 2 4 Series I 91.00 % $140.40

40 1.5 2 4 Series I 94.45 % $140.40

Table 9: Example of choosing switch-points

switch-point would then be a demand of 42 customers per hour.

To test the teams theory, 10,000 replications of each switch-point were run. Only these points were

considered (instead of all 40 scenarios) because we wanted to save time (10,000 replications can take a few

minutes). Three scenarios fell outside of the 90% satisfaction range and a fourth scenario has the half-widththat fell below 90%. These four scenarios were then eliminated from consideration as 90% is the definitive

point assigned by the team.

When a scenario failed the 10,000 replications, the team had to analyze the past data to determine if a

cheaper scenario was available that was not already on the list of switch-points. The team also had to look

for the possibility of a new switch-point. For example, consider Table 10 below.

Peak Pizza Delivery Oven Percent 95% CI Daily

Demand IAT Makers Drivers Type Satisfied H alf-width Cost

46 1.3043 3 4 Series II 90.28 % 0.2676 $178.2945 1.3333 2 4 Series II 90.17 % 0.2783 $159.84

42 1.4286 3 4 Series I 88.28 % 0.3447 $158.85

41 1.4634 2 4 Series I 90.65 % 0.3093 $140.40

Table 10: Example of choosing new switch-points

The test of 45 customers demand failed, as did the following switch-point of 42 customers. For the 45

demand point, the next best option, as far as cost, turned out the be the same as the switch-point for the

demand point 46. The 45 demand point was then able to be lumped into the switch-point for 46. Therefore,

the possibility of changing the switch-point of 45 customers to a different scenario was eliminated. The

next task was to see if a demand of 44 customers would be a new switch-point. The best scenario for 44

customers (for 100 replications) was the scenario of 2 pizza makers, 4 delivery drivers, and an oven loading

size of 520 (2-4-520). This scenario was run for 10,000 replications and passed, therefore making it our

new switch-point. For the 42 demand rate failure, the analysis showed that its next best scenario was 2-4-

520, which was the switch-point for 44 customers; therefore, eliminating it as a switch-point. The new

switch-point table (for this example) is found in Table 11.

26


30/33

Peak Pizza Delivery Oven Percent 95% CI Daily

Demand IAT Makers Drivers Type Satisfied Half-width Cost

46 1.3043 3 4 Series I 90.28 % 0.2676 $178.29

44 1.3636 2 4 Series I 92.24 % 0.2262 $159.84

41 1.4634 2 4 Series I 90.65 % 0.3093 $140.40

Table 11: Pivot table for new switch-points

Afterwards, the team felt it necessary to run more replications of those that narrowly failed during the

100 replication test. 10,000 replications were then run of scenarios that had greater than 87% satisfaction

during the 100 replication test. Of these, three were found to be acceptable and are listen in the Table 12.

Percent Percent 95 % CI

Peak IAT Pizza Delivery Oven Satisfaction Satisfaction Half-width Daily

Demand Makers Drivers Type (100 reps) (10k reps) (10k reps) Cost

36 1.6667 2 3 Series II 89.59 % 90.40 % 0.2109 $178.29

36 1.6667 2 3 Series III 88.73 % 90.40 % 0.2985 $159.8435 1.7143 2 3 Series I 89.82 % 90.90 % 0.2152 $140.40

Table 12: Pivot table for new switch-points

Two of the scenarios that passed were for the same peak demand, therefore, the more costly option was

eliminated. These were then examined to see where they fit in the switch-points. Both these scenarios

were determined to be cheaper than the scenarios we used earlier as the best case scenario. In fact, both of

these also proved to be switch-points. This process was done to update the list of best case scenarios.

The new switch-point table was completed as each demand point was greater than 90% for the 10,000

replications. These final switch-points can be found in Table 13 of section 6.

6 APPENDIX III - Results and Conclusions

6.1 RESULTS & CONCLUSIONS

Table 13 is an extension of Table 1 that includes a 95% confidence interval on the customer satisfaction

levels. The half-widths are given in Table 13 when running the model for 10,000 replications. As can be

seen for Table 13, the average satisfaction level is over 90% with a confidence of at least 97.5%.

One of the suggestions to Miss Sally is that in the event that a satisfaction of higher than 90% is desired,

the store be implemented using one switch point higher than would be suggested by Table 13. To investigate

the effects of such a decision, each of the switch point demand rates were run at the next suggested config-

uration for 10,000 replications. For the 60 pizza per hour case, the delivery resource was the only area with

room for expansion so it was increased to seven. The results of these runs are shown in Table 14. As can be

27


31/33

Customers Number of Number of Average Halfwidth

per Pizza Delivery Oven Percent of 95% Expected

Hour Makers Workers Size Satisfaction Conf. Interval Cost

20 1 2 435 90.81 % .2649 $79.05

23 2 2 435 90.34 % .2166 $97.50

35 2 3 435 90.90 % .2152 $118.9536 2 3 520 90.40 % .2109 $138.39

41 2 4 435 90.65 % .3093 $140.40

44 2 4 520 92.24 % .2462 $159.84

46 3 4 520 90.28 % .2676 $178.29

47 2 5 520 90.49 % .3217 $181.29

49 3 4 605 90.70 % .2036 $194.96

58 3 5 605 90.38 % .2680 $216.41

60 3 6 605 92.01 % .2903 $237.86

Table 13: Recommended configuration switch-points for Sally

seen from these results, the percent satisfactions did in fact rise considerably in most cases. In the few cases

where satisfaction did not rise a great deal, moving up two steps may be considered. For each outcome, the

percent satisfaction for any arrival rate that is slower than the one observed can be assumed to be higher than

that of the observed rate because of the nature of the system that was earlier verified.

Customers Number of Number of Average

per Pizza Delivery Oven Percent Expected

Hour Makers Workers Size Satisfaction Cost

20 1 2 435 94.78 % $97.50

23 2 2 435 99.68 % $118.95

35 2 3 435 91.82 % $138.3936 2 3 520 98.32 % $140.40

41 2 4 435 96.35 % $159.84

44 2 4 520 93.78 % $178.29

46 3 4 520 92.91 % $181.29

47 2 5 520 93.13 % $194.96

49 3 4 605 98.96 % $216.41

58 3 5 605 95.38 % $237.86

60 3 7 605 93.03 % $259.31

Table 14: Minimal potential increase in percent satisfaction levels

7 APPENDIX V - Future Improvements

As with any study of this nature, continuous improvements can always be made to the current progress. Due

to time constraints, the team was unable to implement as many features as are possible for Sally. However,

the list below describes improvements that can be added to the current design for ease of use purposes,

28


32/33

increased robustness in data processing, and in turn, increased profitability.

Obtain 95% switch-points using the same process as the 90% switch-points and give the subse-

quent minimal potential increase by moving to the next switch-point.

With the use of Arena modules and macros, implement a decision support system that takes into

account the customer arrival rate and automatically decides which pizza making process (one, two, or

three person) to enter.

Take into account multiple deliveries for each pizza, as this is more common in practice and would

maximize the available time of the delivery driver.

Maximize use of the unload worker by allowing the worker to assist in the pizza making process when

idle.

8 APPENDIX VI - Raw Data

Please see the accompanying compact disc for all files. If assistance is needed in locating any data, please

contact Richard Ivey1

[email protected] or (256)655-5783

29


33/33

References

[1] W. David Kelton, Randall P. Sadowski, and David T. Sturrock. Simulation with Arena. McGraw-Hill,

3rd edition, 2004.

[2] University of Southern Maine. JPQ - Java Powered Queueing, 2006.

[3] Chan S. Park. Fundamentals of Engineering Economics. Pearson Prentic Hall, 2004.

SM Pizza Report

Documents

Transcript of SM Pizza Report