Sally Model’s SM Pizza Shop

Paul Crane
Randall Frost
Richard Ivey

INSY 3420 – Simulation

Submitted to
Dr. Jeff Smith & Volkan Ustun

May 1, 2006
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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.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
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 total
cost 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
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 into
a 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 Sally’s 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 below
while 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 steps
in 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
 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 Sally’s 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
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 demand
per 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.29
47 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
 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
4 APPENDIX I - Arena Model

4.1 MODEL CONCEPTUALIZATION

In preparing for the simulation modeling process, many preliminary steps were taken before implementing
the 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.

Order Taking Pizza Making Oven Process

batch size dough & saucing what size
Delay of 1.9 min
pizza size primary ingredient
final ingredient
cook time = 7.5 min

Unload Oven
dat file 40% Delivery
assemble boxes
60% Carryout

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
 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 will
simply 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 Sally’s 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 before
the 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
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 queue
of 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 Arena’s 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
 Time dependent observations provided by Sally Distr. 2
9

Distr. 1
6
Time (seconds)

1
0 200 400 600 800 1000 1200 1400 1600

Observation

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
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
entity’s 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
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 the
submodel 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
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 the
current 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 = AssembleP izza.W IP + N Q(W aitf orOven1.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 the
final 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.

P rocessingTime = DoughSauceP T + P rimaryP T + F inalP T (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
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 can’t 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
 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 the
second 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
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 there
to 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
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 the
“Delivery 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, which
is 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
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 having
the 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 customer’s 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 Sally’s 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
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. This
section 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 Sally’s 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 queue
model 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 can’t 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
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 can’t 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 can’t 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 Sally’s shop.

18
 #5 #4

#6

#3 #2 #1

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
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 the
“TotalOrderTime” 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.636
Ending 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.951
Customer 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
“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 number
of 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 system’s 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 percent
satisfaction 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
 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
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, as
Sally 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.

P
satisf ied customers
percent satisf ied = { P } × 100 (3)
total customers

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
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 Arena’s process analyzer. Additionally, a con-
siderable amount of time was used for the debugging process in Arena’s process analyzer as the team had
defined the response statistic as “% Satisfied.” Apparently, the process analyzer does not accept the “%” sign
as 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.45
2 $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
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).

Peak Pizza Delivery Oven Percent Daily

Demand IAT Makers Drivers Type Satisfied Cost
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
 Peak Pizza Delivery Oven Percent Daily
Demand IAT Makers Drivers Type Satisfied Cost
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 team’s 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-width
that 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 Half-width Cost
46 1.3043 3 4 Series II 90.28 % 0.2676 $178.29
45 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
 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.84
35 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
 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.95
36 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.39
36 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
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

1
iveyria@auburn.edu or (256)655-5783

29
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.

30