Simulation of Starbucks outlet at University of Cincinnati using Arena.

1. Simulation of
Starbucks
Project Report
Rashmi Subrahmanya
12-3-2017

2. i
Contents
Table of figures ..........................................................................................................................................i
Tables........................................................................................................................................................ ii
Acknowledgement.....................................................................................................................................i
Introduction ..............................................................................................................................................1
Objective of the study...............................................................................................................................1
Description of the current process ...........................................................................................................1
Assumptions..............................................................................................................................................1
Data Collection..........................................................................................................................................2
Fitting data................................................................................................................................................2
Arena Model .............................................................................................................................................2
Results...................................................................................................................................................8
Alternate Scenarios.................................................................................................................................10
Conclusion...............................................................................................................................................12
References ..............................................................................................................................................12
Appendix .................................................................................................................................................12
Table of figures
Figure 1: Arena Model ..................................................................................................................................2
Figure 2: Create Module ...............................................................................................................................3
Figure 3: Entity..............................................................................................................................................3
Figure 4: Decide Module...............................................................................................................................3
Figure 5: Assign Module................................................................................................................................3
Figure 6: Attributes.......................................................................................................................................4
Figure 7: Process Module..............................................................................................................................4
Figure 8: Record Module...............................................................................................................................4
Figure 9: Variable..........................................................................................................................................5
Figure 10: Separate Module .........................................................................................................................5
Figure 11: Batch Module...............................................................................................................................5
Figure 12:Dispose Module ............................................................................................................................6
Figure 13: Queue...........................................................................................................................................7
Figure 14: Resources.....................................................................................................................................7
Figure 15: Set ................................................................................................................................................7
Figure 16: Expression....................................................................................................................................7
Figure 17: Statistic.........................................................................................................................................8
Figure 18: Process Analyzer output ............................................................................................................11
Figure 19: Alternate scenario with one additional cashier and barista......................................................11

3. ii
Figure 20: Base Scenario.............................................................................................................................11
Tables
Table 1: Order types......................................................................................................................................5
Table 2: Entity, Resource, Queues ................................................................................................................6

4. i
Acknowledgement
I would like to thank Professor David Kelton for guidance provided during the course of project.
I would like to express my gratitude to employees of Starbucks, College-Conservatory of Music,
UC, who provided valuable information and granted me the permission to collect data.

5. 1
Introduction
Starbucks is an American coffee company and coffeehouse chain with nearly 24000 locations
worldwide. This project aims to simulate Starbucks coffee store at College-Conservatory of
Music(CCM), University of Cincinnati, using Arena. Modelling in arena helps to analyze average
total time of customers in system, waiting times in different queues, total number of customers
served, utilization of resources, etc.
Starbucks (CCM) is open from 7.30 am to 10 pm during weekdays and from 10 to 5 pm during
weekends. Generally, the store is busiest between 11.30 am to 2 pm and 4 to 6 pm. According to
an employee, during the rush hours, the wait time could be anywhere between ten to twelve
minutes and there could be up to 15 people waiting in billing counter queue. This could result in
customers leaving the store without making any purchase and deter prospective customers from
entering the store. This results in loss of customers for the store.
Objective of the study
To study the average total time in system for customers and provide suggestions to minimize
average length of stay in the system.
Description of the current process
Customer enters the store, may or may not wait in queue and goes to billing counter. Here, the
customer inquiries about a product (hot/cold beverage/food), places his/her order if it is available
and pays the amount. The cashier marks the order type and the resources then go to respective
counters (hot beverage, cold beverage, food) based on the order and prepare it. The customer
collects the order and then leaves the counter. The customer may choose to sit in the store or leave.
Demand varies with time and season. Customers prefer hot beverages over cold beverages during
morning and evening hours and in winter and autumn seasons. More customers order food during
lunch hours as compared to other times of the day.
Assumptions
Assumptions used in the model are as follows:
• Model is simulated from the time customer enters the store till the time he/she receives the
order, at which point the customer exits the system. It does not consider self service time
such as time taken to add sugar and get napkins or the time that a customer spends in the
sitting area.
• There are three counters in the system – billing counter, food counter and beverage counter.
Each counter has one resource.
• Data for decision module is obtained from employees as well as from data collected.
• Beverage processing time and food processing time is independent.

6. 2
• The model assumes that there are no breaks in the time it is run.
Data Collection
Data was collected manually after obtaining the necessary permissions from employees working
at Starbucks, CCM, UC. Inter-arrival time of the customers and service time was noted. Service
time was noted for different processes i.e, preparation of hot beverages, cold beverages and food.
Data was collected for an hour from 12 to 1 pm, which is one of the busiest hours in a day. Since
data was collected in afternoon, there are more number of customers opting for food.
From interaction with the employees and data collected, it was observed that nearly 1% of the
customers leave without placing any order due to non-availability of products. Among those who
place an order, approximately 50% of customers ordered only hot beverages, 20% only cold
beverages, 17% ordered only food, 10% ordered food along with hot beverage and rest ordered
food along with cold beverage.
Fitting data
To build a model in arena, data is given as input in the form of distribution. For each of the process,
data was fitted to a distribution using Input Analyzer. The Input Analyzer takes the data, which is
saved as .dst file, and gives a best fit distribution. Distribution was obtained for inter-arrival time
of the customers, service times for billing, hot beverage, cold beverage and food. The histograms
and summary of distributions are attached in the appendix.
Arena Model
Below is the layout of the model:
Figure 1: Arena Model

7. 3
The following steps and modules were involved in building the model
1. Customer enters the store – A create module is used to show customer entering a store. It
basically creates an entity, which is customer in this model. It creates entities based on the
expression for inter-arrival time of customers which was obtained from input analyzer.
Only one type of entity is used in the system, named customer. A picture is assigned to t
the entity.
Depending on the length of queue at billing counter, a customer may choose to exit the
store without placing any order. It was observed that if number of customers in the queue
is equal to or greater than 8, then a customer exits the system.
Figure 2: Create Module
Figure 3: Entity
Figure 4: Decide Module
2. Once an entity is created, it is assigned an arrival time using inbuilt function TNOW. This
is used later in the model to calculate length of stay in the system.
Figure 5: Assign Module

8. 4
Figure 6: Attributes
3. Customer may or may not wait in queue to place an order depending on the queue. The
queue is shown in animation.
4. Customer seizes cashier and inquires about a product at billing counter. This is shown by
a process module and the action is ‘Seize Delay’. A decide module is used to make decision
about placing an order (Figure 4). If the desired product is not available, the customer
releases cashier and exits system. A release module is used to release cashier and record
module is used to record the number of customers who exit the system due to non-
availability of desired product.
Figure 7: Process Module
Figure 8: Record Module
5. Other customers place an order at Billing Counter and pay for the order. This is shown
using a Process module (Figure 7). The expression is obtained from billing time using input
analyzer. In this case, the action is ‘Delay Release’.
6. After this process module, an Assign module is used to assign order types, beverage
processing time and food processing time (Figure 5). A variable array is initiated to count
number of customers by order type.

9. 5
Figure 9: Variable
A one-dimensional variable, CensusByOrderType, is used to store number of customers
based on order type.
Below are the order types used in the project:
Table 1: Order types
Order Type Description
1 Hot beverage only
2 Cold beverage only
3 Food only
4 Hot beverage and food
5 Cold beverage and food
7. The order is separated based on the order type to beverage and food counters which are
represented by two process modules.
Figure 10: Separate Module
8. Beverage processing module has one resource named barista, who prepares both types of
beverages (Figure 7). The processing time is based on order type and is given as an
expression. Similarly, for food processing module, there is one resource named food server,
who prepares food. The processing time is given as an expression.
9. A batch module is used to combine orders which have beverage and food since they are
processed at different counters. The order is combined using inbuilt entity attribute -
Entity.SerialNumber, a number assigned to entity when it is created. If it is single order
such as food or beverage only, it is collected by customer.
Figure 11: Batch Module

10. 6
10. At this point the process is completed and the customer exits the system. Before exiting, a
Record module is used to record the number of customers based on order type and another
record module is used to record the time interval between TNOW and the exit time (Figure
8). This gives the average length of stay for a customer in the system.
Figure 12:Dispose Module
Table below shows entities, resources and queues in the model:
Table 2: Entity, Resource, Queues
Entity Customer
Resource 1 Cashier Seize Delay, Delay Release
Resource 2 Food Server Seize Delay Release
Resource 3 Barista Seize Delay Release
Queue Billing Counter FIFO
Queue Food Processing FIFO
Queue Beverage Processing FIFO
Queue Collect Order FIFO
Four attributes have been used:
• Arrival Time – To assign arrival time for customers
• OrderType – To assign type of order. There are 5 types numbered 1 to 5
• Beverage Processing Time – To assign processing times based on whether the
beverage is hot or cold
• Food Processing Time – To assign food processing time
Queue:

11. 7
Figure 13: Queue
There are four queues – one each at billing counter, beverage processing counter, food
processing counter and collect order counter.
Resources:
Figure 14: Resources
There are 3 resources – cashier, barista and food server.
Set:
Figure 15: Set
To store count of customers by order type.
Expression:
Figure 16: Expression
BeverageProcessingTimeExpr and FoodProcessingTimeExpr store beverage and food processing
times respectively, based on order type.

12. 8
Statistic:
Figure 17: Statistic
To record number of customers based on order type. For example, Census by Order type 1
records number of customers who place an order of type 1.
Results
The model was run for two and half hours and for 50 replications. The following results were
obtained after completing the simulation:
1. Total number of customers completely served and exited from the system is 100.
2. Average Length of Stay (LoS) in the system for all types of customers is 3.6057 minutes
with half width of 0.16 minutes. However, maximum time in the system is 12.4095
minutes.
3. Queues:
If we look at the queue, the average waiting time is highest for billing counter queue with
a value of 1.1234 minutes. The maximum value of waiting time is 9.9576 minutes and
maximum number of people waiting is 9, both for billing counter. This may lead to balking
or reneging and thus, loss of customers for Starbucks.

13. 9
4. Scheduled utilization of resources
It is observed that the most utilized resource is cashier, followed by barista and food server
respectively.
5. User specified
Record modules were used to record number of customers based on order type and it is as
shown below. It is observed that hot beverages are most preferred products of Starbucks.

14. 10
From the outputs, it can be inferred that cashier has high utilization and billing counter has
highest waiting time in queue and the number of customers waiting in queue. The average
LoS in the system is 3.6057 minutes. We will look at alternate scenarios to see if average
LoS can be reduced.
Alternate Scenarios
The following alternate scenarios were compared using Process Analyzer:
• Base scenario with one resource each
• Adding one barista without changing other resources
• Adding one cashier without changing other resources
• Adding one barista and one cashier without changing other resource

15. 11
Figure 18: Process Analyzer output
From the process analyzer output, the best scenario is to add one each of barista and cashier. After
running the model with one extra cashier and one extra barista, we get the following tally output:
Figure 19: Alternate scenario with one additional cashier and barista
Figure 20: Base Scenario

16. 12
Comparing with base scenario, the average LoS in system has reduced to 2.418 minutes from
3.6057 minutes and half width also reduced from 0.16 to 0.05 minutes. Thus, with alternate
scenario, we can say that the average LoS in the system will lie between 2.3683 to 2.4683 minutes.
Conclusion
Based solely on above analysis, it is recommended to add one cashier and one barista to reduce
average LoS of customers in the system. However, it is necessary to consider economic
implications of adding two resources i.e, the benefit of adding new resources versus the cost.
Alternatively, we could look at adding part time resources during peak hours.
References
• Kelton, D. W., Sandowski, R. P., & Zupick, N. P. (2015). Simulation with Arena (Sixth Edition).
McGraw Hill.
Appendix
Distribution obtained from Input analyzer (Time in minutes):
Inter-arrival time of customers:

17. 13
Service Time at billing counter:

18. 14
Time required to make payment:
Input analyzer was not used. Uniform distribution (0.33, 0.67) was used.
Service time at Hot Beverage Counter:

19. 15
Service time at Cold Beverage Counter:
Service time at food counter:

20. 16