The document provides an analysis of the operational processes that make up the service model of Provino's Italian Restaurant using Arena simulation software. It first describes the key entities, resources, variables, and attributes that define the restaurant's system. It then outlines the main stages of the customer service process through a series of process flow diagrams. These include customer arrival and seating, appetizer/entree/dessert ordering and preparation, food delivery, bill payment, and customer departure. The document also discusses data collection efforts and presents results comparing the average time customers spend in the average weekday and weekend peak hour simulation models. Analysis of the results will help identify areas of the system that could be improved.

1. Kembel 1
Ryan Kembel
ECON 4850
Provino’s Italian Restaurant Simulation Project
December 8, 2015
Simulation Project Report
This report focuses on analyzing some of the operational processes that collectively
create the Provino’s Italian Restaurant service model. Since there are many subtleties and
interdependent processes within dine-in restaurant service models, designers of the system may
make many mistakes in system design, resource procurement and allocation, and overall lack of
awareness of how system inefficiencies may affect customers. In the end, one must evaluate a
service system’s effectiveness by how customers are effected, since revenues and profits are
dependent on meeting customer expectation and understanding their spending habits.
The main problem analyzed in this report will be multifaceted. First, a system that
accurately reflects the real-world restaurant service system will be designed utilizing Arena
Simulation software. Second, by analyzing the output data, system inefficiencies and areas for
potential improvement must be identified. Then these adjustments will be implemented in the
development of revised systems. Lastly, the output data of both systems will be analyzed to
identify how the system has improved and possible implications for the restaurant manager. This
study strives to gain an understanding of the system and offer Provino’s Italian Restaurant
management knowledge, areas of suggested system revision, and proposed solutions to problems
currently affecting system effectiveness. Additionally, system adjustments can be tested in this
simulation which would be costly and impractical to test within the real-world system.
Understanding this system starts with knowing the fundamental pieces that complete the
system. The table below will provide details about system entities, resources, variables and
attributes. Subsequently, a process flow will be provided to visually express the entire system.
Entities
Customers
As the process flow will express, customers will be separated into to
classifications of boothcustomers and tablecustomers. These entity
types have unique attributes that will be called throughout system
processes in order to apply the correct service times.
Resources
Tables Customers that are classified as table customers will seize a table for
the duration of their time in the system.

2. Kembel 2
Booths Customers that are classified as booth customers will seize a booth for
the duration of their time in the system.
Servers
These resources are separated into two classifications: booth servers
and table servers in order to correctly associate them with the
customers they are assigned.
Food Runners These individuals sole purpose is to bring food that has been prepared
by kitchen resources to customers.
Cashier The cashier resource is used to process all cash payments required for
customers to leave the system.
App Fryers
Appetizer fryers are used to prepare all appetizers that are ordered by
customers. Some appetizers in the system are not prepared using the
appetizer fryers, but other resources that are used by the same cooks
that prepare all appetizers, therefore no differentiation is made.
Dessert Station
This utilizes one cook as the resource who prepares all desserts that
customers order. All requirements are easily accessible and desserts are
typically prepared quickly, however, not necessarily simultaneously.
Oven
The oven resource is used to prepare all baked entrée dishes, as well as
the cooks that operate the oven. This oven is large enough to prepare
multiple dishes simultaneously.
Sautée Station This resource represents the portion of the kitchen dedicated to entrees
that require a stovetop and sautée chef for preparation. There are many
burners so that the cook can prepare different dishes at the same time.
Pasta Station
The pasta station resource represents the cook and part of the cook line
required to prepare pasta dishes. Since these dishes only require boiling
water and sauces, preparation of multiple dishes is simple and fast.
Card Machine
The card machine resource is used to process all debit, credit, or
prepaid transactions required for customers to leave the system. Card
transactions must be processed one at a time with a per transaction fee
cost to the merchant.
Attributes
booth_index
This attribute is saved at service processes in order to designate the
type of entity to utilize the correct service time distribution. The
booth_index is also used to state that a booth is released after
customers leave the system.
table_index The table_index attribute is used to designate that a table is released
when a table customer leaves the system.
app order
This attribute is used to designate the time required for customers to
order an appetizer. There will be a difference in ordering time
depending on the entity type.
ordering The ordering attribute will differ from booth or table customers and
will be called when customers order their entrée.
order dessert
This attribute defines the time distribution for customers that order
dessert. A different distribution will be used for booth customers versus
table customers.

3. Kembel 3
close bill
The close bill attribute assigns a time distribution for the time taken to
close a customer bill and prepare for payment processing. Different
time distributions will be assigned for different entity types.
Variables
boothcustomers This variable is used to keep a total count of booth customers in the
system. This count will be used in the system’s terminating condition.
tablecustomers This variable is used to keep a total count of table customers in the
system. This count will be used in the system’s terminating condition.
maximumarrivals This variable states that an unlimited number of arrivals are allowed
while the system is open.
customersperarrival This represents the number customers that arrive. The variable states
that customers arrive one at a time.
A series of process flow diagrams will be presented below. Collectively, these processes
create the system in its entirety.
The above series of processes begins with customers arriving individually. Upon arrival,
customers are separated according to a percentage collected from the data collected. After being
separated, customers are assigned attributes based on whether they are a booth or table customer.
These attributes were mentioned above and will be used in the different stages of service
processes. Next, customers will seize either a table or booth. There is a maximum number of
tables and booths available, but customers seize any available seat upon entering the Seize
module. Lastly, there is an Assign module that maintains a count of customers in booths or
tables, and increases the count by one with each additional customer. This Assign module will be
used in the terminating condition which will be discussed at the end of the module. The separate
paths from the Assign modules will converge and combine at the next process stage.

4. Kembel 4
As stated above, the two previously separated paths combine and enter the Decision
module, which determines whether customers will order appetizers. The likelihood of ordering a
dessert is the same for either booth or table customers, and was derived from collected data.
However, if customers do not order appetizers, the subsequent processes will be skipped and
customers will enter entrée ordering process stage. If customers decide to order appetizers, they
proceed to the ordering app time process module which determines the time distribution for how
long customers will take to order. This distribution is different depending on entity type. To
begin the ordering process, customers enter the Seize Server for App Order process module,
where the server that is the least busy will be seized. After the server takes the customer order,
the server process moves into the placing app order delay module. After the order is placed, the
server is released and can be seized by another customer. Since the order has been placed, it will
move into the Appetizer Prep process module which seizes the app prep resource in the kitchen
to prepare the appetizer. All appetizers follow the same time distribution for preparation delay
until they are ready for the customer. After leaving the Appetizer Prep process module,
customers will enter the next process stage.
Whether or not customers order appetizers, eventually they will enter the entrée ordering
process stage shown above. This stage is identical to the appetizer ordering stage, with the
exception of the time customers take to order their entrée versus the appetizer. Additionally,
customers can decide to not order an entrée and proceed directly to the dessert ordering process
stage. From the placing entrée order module above, customer orders move into the entrée
preparation process stage.

5. Kembel 5
The entrée preparation process stage above shows the stages of separating orders into the
proper station in order to utilize the correct resource. Following completion, the order will enter
the bring food process where the food runner resource is seized in order to bring the order to the
customer. Before reaching the customer, the order passes through a Decide module to determine
whether it will go to a booth or table customer. This is necessary in order to separate orders
according to the time distribution for the delay that customers need to eat the meal. Since booth
and customers take a significantly different amount of time to finish their meals, this separation
is required. Customers will then leave the eating delay module to enter the dessert ordering
process stage.
The above image shows the dessert ordering process stage and the closing of the
customer bill process stage. The dessert ordering process stage is identical to the entrée and
appetizer ordering stages. Customers decide whether a dessert will be ordered, if no dessert is
ordered, the stages of seizing a server, ordering, placing the order, preparing the dessert and
eating the dessert are skipped, and the customer enters the bill closing stage. Similar to the
previous stages, in order to close the customer bill, the correct time distribution must be selected
corresponding to the customer type. Then the server is seized, the bill is closed and the server is
released. After the Release3 module, customers will enter the payment processing stage.

6. Kembel 6
The payment processing stage shown above is the last stage of Provino’s Italian
Restaurant service model system. All customers, whether appetizers, entrees, or desserts were
ordered will enter this stage beginning with the Cash or Card module. Following the closing of
the customer bill in the previous stage, the customers now decide whether to pay with a card or
cash. The percentage that customers pay with a card was determined using the collected data.
When customers pay with a card, the card machine resource is seized and the payment is
completed. Alternatively, if cash payment is decided, the cashier is seized and the transaction is
completed. After completing the payment for their bill, customers then leave the restaurant. The
booth or table leave decide variable separates customers that seized a booth, and those that
seized a table, so that the correct resource and can be released at the release booth and release
table modules. Lastly, the two Assign modules decrease the number of customers in booths or
tables by the number of customers that leave the system. These last functions are maintain the
count so that the terminating condition will begin when all booth and table customers have exited
after the simulation time has been exceeded.
This simple model is entirely separate from the Provino’s restaurant system model. The
above model is used to create one entity, THE TERMINATOR which signifies Provino’s “doors
closing”. The entity is created at the desired ending of arrival of new customer entities in
restaurant system model. After the arrival and disposal of this single entity, no additional entities
will enter the Provino’s model allowing all existing entities to finish their complete the process
stages and exit the system. The addition of this model allows for the use of a terminating
condition which ends the simulation after all entities have exited the system. This was done in
order to more accurately represent how a real-world restaurant system would operate.

7. Kembel 7
The entire Provino’s Italian Restaurant service system model is presented below with all
of the above stages included.
This model could be utilized to analyze many different aspects of the restaurant system.
However, the scope of this study will focus on processes that unnecessarily slow customers as
they move through the system such as resource capacity and the ability of the system to move
customers efficiently. Some processes such as order taking and order preparation will not be
analyzed for improvement unless excessive queues form that significantly delay customers.
Determining whether excessive customer delay is present in certain processes will be
accomplished by learning from servers and other “experts” of this restaurant system that know
customer and management performance expectations.
Data Collection
Data collection efforts focused on understanding customer tendencies. By reviewing
multiple days of restaurant checks, a database was compiled which included whether customers
were sat a table or a booth, whether the customer ordered an appetizer, entrée or dessert, and

8. Kembel 8
whether customers paid with cash or a card. By summing the counts of these variables,
percentages of likelihood for each customer decision making was generated.
Additionally, Provino’s management and servers familiar with the system were consulted
to determine estimations of customer tendencies, and resource capacities. Management provided
estimations on preparation time for appetizers, entrees and desserts, as well as the capacity of
resources seized for preparation. Multiple servers were consulted to determine delays for placing
customer orders, closing bills, and estimations of time taken by customers to eat meals and
desserts. It should be understood that customer actions within the restaurant system fluctuate
greatly. Considering this, slight adjustments to the percentage estimates of customer tendencies
were made in hopes of more accurately representing the system outside of the three days of
checks used to create the original dataset.
Some difficulties were managed when modeling the real-world system. The simulation
model encounters customers on an individual basis, instead of a by-table basis. In the real-world
system, customers arrive in batches. If a group of four or less, more than likely, that group will
be sat in a booth. Conversely, if a customer group is greater than four, that group will be sat in a
table instead of a table. The grouping of customers significantly impacts the bill closing process
because a single check or multiple individual checks may be required. Additionally, the group of
customers requiring a table could exceed twenty individuals, which compounds the problem of
bill closing, but also complicates ordering processes. These complications were attempted to be
mitigated by increasing the range of the time distribution of table customers compared to booth
customers.
Provino’s Italian Restaurant often reserves a significant amount tables and multiple
servers if customers request a private room or to have a table ready upon their arrival. This
would significantly impact overall system performance in terms of resource utilization and
increased queue for multiple processes. One must understand how this model may fall short of
accurately representing the real-world model by omitting customer reservations. Lastly, the
simulation model does not include the process of cleaning and resetting tables or booths for the
next customer. This process has a significant impacts the customers’ ability to seize a table or
booth and server in the real-world system. These above omission and adjustments of the real-
world system may have decreased the model’s accuracy, however the model still truly reflects
the inherent processes in order to satisfy the average customer needs.
Given the regular fluctuation of customer arrival on a typical weekday versus a dinner
rush weekend night, two system models were created. The only differences between the models
are customer interarrival times, available servers to be seized by customers, food runner
resources available, and overall model duration. Creating two models was important because the
restaurant must be designed to operate at a much greater capacity than the average hourly
operation level during weekday mornings and afternoons.

9. Kembel 9
Average Weekday
Model
Weekend Peak Hours
Model
Model duration 480 minutes (8 hours) 180 minutes (3 hours)
Interarrival time EXPO: 3 minutes EXPO: 1.5 minutes
Servers Available 4 Booth, 3 Table 5 Booth, 6 Table
Food Runner Resource 1 resource 3 resources
While these models are significantly different, the fundamentals, in terms of kitchen
resource capacity have remained constant. After running these models it is clear that the Average
Weekday Model shows few room for improvement. Therefore, what-if scenarios and
improvement recommendations will be made based on the Weekend Peak Hours Model since
this model demonstrates how the system performs when operating at the level it was designed to
handle. Significant changes to kitchen capacity, payment processing or order placing will
improve both models’ efficiency level, but improvement during peak hours will be the more
important measure.
Simulation Model Results & Analysis
Entity Analysis
The table below shows the total time in system for all customers in both systems. Clearly
there is a significant difference between the two models, which can be attributed to the increased
number of entities entering the system. However, identifying delays or processes that hamper
system efficiency, and implementing potential improvements may lower the total time in system
for both models. Additional analysis is required to understand what part of the system is causing
the increase in time entities spend in the restaurant.
Average Weekday Model Weekend Peak Hours Model
Total Time in System Total Time in System
AVG MAX AVG MAX
Booth Customers 39.28 58.66 47.91 77.50
Table Customers 55.37 74.04 63.43 95.73
For this system, entity relevant time measures will be broken down into three categories.
Value Added time is the combination of server various server interactions such as seizing a
server and ordering. Non-Value Added time is delay caused by customers when they are not
needing service because they are eating entrees or desserts. Wait time is a combination of
appetizer, entrée, and dessert preparation, server delay processes such as placing orders and
closing bills, and payment processing before customers leave the system. Lastly, Transfer time is
the time taken by food runner resources to deliver orders. These metrics will determine the
efficiency of the Provino’s system from a customer perspective. Below is a comparison of the
Average Weekday Model and the Weekend Peak Hours Model by the above time metrics.
*Units: Minutes

10. Kembel 10
BOOTH CUSTOMERS
Average Weekday Model Weekend Peak Hours Model
AVERAGE MAXIMUM AVERAGE MAXIMUM
Non-Value Added time 20.62 32.95 21.05 34.76
Value Added time 3.47 9.80 4.08 10.46
Wait time 13.71 21.44 21.34 37.15
Transfer Time 1.46 2.91 1.43 2.82
TABLE CUSTOMERS
Non-Value Added time 32.59 45.23 33.61 49.10
Value Added time 7.77 14.83 8.26 18.86
Wait time 13.57 20.70 19.95 40.34
Transfer Time 1.43 2.60 1.60 2.89
The previous table shows the significant difference between peak business hours and
average weekdays. As expected Non-Value Added time remains relatively constant because it is
customer dependent. Wait time and Value Added Time are dependent on resource availability
and customer arrival rate. Management’s scheduling practices and management of resources
seem manage Value Time sufficiently when comparing the two systems, so one could conclude
there enough available resources to take customer orders. Additionally, the difference in Value
Added Time for table customers compared to booth customers should be expected, since table
customers seize servers for longer periods of time. The most important difference between
systems lies in the Wait time for customers. Since Wait time is component of preparation of
appetizers, entrées, desserts and server related delays, there may be resources other than servers
that should be adjusted to meet the increased demand from customers. Analyzing resource
utilization and queues will provide further insight.
Resource Analysis
Average Weekday Model Weekend Peak Hours Model
AVG
INST.
UTIL (%)
Waiting Time
(minutes)
AVG
INST.
UTIL (%)
Waiting Time (minutes)
AVG MAX AVG MAX
App Fryers 13.60 .07 2.24 49.94 1.34 7.60
Oven 26.83 0.00 0.00 64.06 1.81 8.92
Pasta Station 12.67 .36 2.73 39.20 1.21 4.88
Sautee Station 5.96 0.00 0.00 14.70 0.00 0.00
Dessert Station 3.23 .02 .48 9.83 .08 .79
Food Runner 44.67 .59 4.89 41.06 .09 1.21
*Units: Minutes

11. Kembel 11
Cashier 17.50 .26 2.31 46.02 1.61 9.56
Card Machine 24.41 .18 2.09 70.19 7.03 17.17
The table shown above provides important metrics that measure the utilization and
efficiency of resources excluding servers. These resources are used in processes that contribute
to Wait time delay for customers, and cannot be affected by adjustments to the server resources.
While continuing to compare the two systems, it is evident the Cashier and Card Machine
resources may be the most influential resource factors increasing Wait time for customers. This
suggestion is supported by the number of entities waiting in queues according to the table below.
Considering these improvements, once again, should be founded on the resource performance,
more so than the Average Weekday Model. Any increase in efficiency will most likely be
reflected in both models, if improvements were implemented.
Average Weekday
Model
Weekend Peak
Hours Model
Number Waiting Number Waiting
AVG MAX AVG MAX
Oven 0.00 0.00 .82 7
App Fryers 0.00 1 .28 3
Cashier .027 2 .43 6
Card Machine .03 2 3.83 13
Some of the above errors may be a result of minor data extrapolation, which could lower
the accuracy of the simulation model. This may be a result of data estimation, which could be
remedied with additional data collection on each process, mainly the processes associated with
payment processing and utilization of the cashier and card machine. However, overall, the
model simulates the real-world system accurately. For both models, the time entities spend in the
system is close to the estimates provided by Provino’s staff and management. Additionally,
delays among kitchen resources accurately reflect the current real-world system during peak
hours. Expecting near zero delay in a kitchen during the scenario being simulated is unrealistic.
Therefore, since most service times, delay times, and customer time in system is close to staff
and management estimates, the simulation model is acceptably accurate. Given the simulation
model is reliable, potential solutions to excessive delays and what-if scenarios may be
investigated.
System Adjustments & What-if Scenarios
Identifying improvements to Weekend Peak Hours Model will begin by focusing on the
resources that are increasing customers Wait time in the system. All other resources and
processes are generally efficient, and these areas should be relatively easy to adjust, and lead to
significant improvement. The overall system will be changed, but rather the capacity or
availability of the resources used. Cost will be taken into account for these adjustments, and
while multiple suggestions may be proposed, some cases may provide a marginally improved

12. Kembel 12
system, at significantly higher cost. Therefore, identifying system changes that incrementally
increase costs to small degree, but significantly improve the system performance will be goal.
The tables below will compare the various system changes by the same metrics that were
used to identify potential areas of improvement, including total customer time in system and
Wait time.
Weekend Peak Hours Model Adding 1 Card Machine
Booth Table Booth Table
AVG MAX AVG MAX AVG MAX AVG MAX
Wait Time
(minutes)
21 37 19 40 14 31 14 26
Total Time In
System
(minutes)
47 77 63 95 39 62 57 81
Weekend Peak Hours Model Adding 1 Card Machine
Number
Waiting
AVG
INST.
UTIL
(%)
Waiting Time
(minutes) Number
Waiting
AVG
INST.
UTIL
(%)
Waiting Time
(minutes)
AVG MAX AVG MAX
Card Machine 3.83 70.19 7.03 17.17 .06 29.47 .13 2.17
As the two tables above indicate, simply adding one credit card machine decreases Total
Time in System and Wait for customers significantly. The average wait time for booth and table
customers decreased by 7 and 5 minutes respectively. Additionally, the average card machine
utilization was reduced by a difference of 40.72%, and the average time for server waiting to use
the card machine decreased from 7 minutes to 7.8 seconds. Also, the most a server would have to
wait to use the card machine decreased from 17.17 minutes to 2.17 minutes. Lastly, the average
queue length decreased from 3.83 to .06. These process improvements are important to the
system because it saves both customers and servers’ time, while minimizes delay.
The second recommended improvement will build on the previous, by adding an
additional cashier to process cash payments. This adjustment includes adding the additional card
machine.

13. Kembel 13
Weekend Peak Hours Model Adding 1 Card Machine &
Cashier
Booth Table Booth Table
AVG MAX AVG MAX AVG MAX AVG MAX
Wait Time
(minutes)
21 37 19 40 15 26 14 23
Total Time In
System
(minutes)
47 77 63 95 40 61 57 77
Weekend Peak Hours Model Adding 1 Card Machine &
Cashier
AVG
Number
Waiting
AVG
INST.
UTIL
(%)
Waiting Time
(minutes)
AVG
Number
Waiting
AVG
INST.
UTIL
(%)
Waiting Time
(minutes)
AVG MAX AVG MAX
Card Machine 3.83 70.19 7.03 17.17 .06 36.27 .44 3.34
Cashier .43 46.02 1.61 9.56 .25 15.99 .03 .82
The two tables above show that adding the second cashier in addition to the card machine
can improve the system. However, the improvement is not as drastic as the previous model.
Average utilization decreased by a difference 30.03%, which should be expected given the
double of number of cashiers. The average number waiting to seize the cashier for payment
processing decreased slightly, but not enough to suggest a significant improvement. Similarly, no
significant decrease in Wait time result from the additional resource. The main positive of the
additional cashier is the decrease in average waiting time, which decreased from 1.61 minutes to
.03 minutes. Also, the most a server waited to seize the cashier decreased from 9.56 to .82
minutes.
The last what-if scenario to be considered will be the installing of a computer system for
order and payment processing. This scenario changes the system considerably more than the
previous two scenarios. Provino’s Italian Restaurant may be “out dated” in the sense that all
customer bills are hand written by servers on multi-sheet slips, with one layer for appetizer
orders, another for entrée orders, and the bottom layer for totaling up the bill closing the bill with
the customer, and processing the payment with the card machine or cashier. Eliminating the
paper system and using a computer system will change the way all orders are placed, how bills
are closed, and how payments are processed. Since this scenario directly affects a server
processes, slightly different metrics will be used to determine whether the adjustment improves
the overall system.

14. Kembel 14
The table above compares the three what-if scenarios by the common metric of customer
Wait time. Ten replications were generated to calculate the mean Wait time for each system. One
can conclude with 97.5% confidence that the Computer System module will reduce customer
Wait time by an interval of 2.91 minutes to 6.68 minutes compared to the Weekend Rush Model,
1.06 minutes to 4.12 minutes when compared to adding one additional card machine, and .89
minutes to 3.73 minutes when compared to the addition of an additional card machine and
cashier resource. The table below offers further insight into how each model adjustment
improves customer Wait time. Each new model is compared to the original Weekend Rush
Model to show the by minute interval improvement. This table supports the previous conclusion
that the Computer System model offers the greatest improvement of customer Wait time.
Management should also take into consideration the financial and system implications of
these changes. The most direct consequence of implementing these changes are the financial
costs of installing a computer system, purchasing and using another card machine, and
purchasing a new register, in addition to the salary of an additional cashier. No model showed a
significant difference in the number of customers that move through the system, but that could be
a product of the length of the simulation, and does not account for changes in customer arrival
Sample size 10.00 10.00 10.00
Mean(Zj) -4.80 -2.59 -2.31
Var(Zj) 4.93 3.23 2.80
Lower limit -6.68 -4.12 -3.73
Upper limit -2.91 -1.06 -0.89
alpha 0.10 0.10 0.10
alpha_hat 0.025 0.025 0.025
Computer System VS
Adding Card Machine
and Cashier
Computer System
VS Weekend Rush
Model
Computer System
VS Adding Card
Machine
Sample size 10 10 10
Mean(Zj) -2.210 -2.491 -4.800
Var(Zj) 6.087 2.526 4.930
Lower limit -4.305 -3.841 -6.685
Upper limit -0.115 -1.142 -2.915
alpha 0.1 0.1 0.1
alpha_hat 0.025 0.025 0.025
Computer System
VS Weekend Rush
Model
Adding Card Machine
VS Weekend Rush
Model
Adding Card
Machine & Cashier
VS Weekend Rush
Model
Model 1 Model 2 Model 3

15. Kembel 15
rate. The most important benefit for any of the three models is the decrease in Wait time.
Customers will most likely have a better experience if they spend less time waiting on their
service. Improving in customer experience could pull in additional customers which would
increase Provino’s exposure and revenue income.
The costs associated with each system is another factor in deciding on system changes.
Costs can be categorized in terms of system efficiency and financial expense. While the above
evidence suggests the system will be efficient, implementing any of the models requires
additional time and resource allocation to obtain the necessary new resources, train employees
and management effectively, and maintain the new system model.
For example, when comparing the three models, conceptually, Model 1 offers the lowest
cost because one additional card machine requires minimum training and a marginal increase in
expenses associated with card payment transactions. Employees will not have to be trained to use
the machine, because it will be identical to the card machine currently in use.
In Model 2, management must obtain an additional
cash register, as well as potentially hire and train another
employee to operate the cashier, assuming there is not another
cashier available to work weekend shifts. While Model 2 may
offer a greater average improvement of customer Wait time,
the costs of the additional employee. Most importantly, since
the confidence interval to the right contains 0, there may be no
real differences in customer wait time between Model 1 and
Model 2.
Lastly, as proven above, Model 3 offers the greatest
improvement of Wait time for customers. Also, Provino’s may benefit from better inventory
awareness and control, as all transactions are documented in the computer database. However
this model would require the greatest investment and cost to the company. Since no computer
check control system is currently being utilized, site renovations would be required to install and
connect the computer network, in addition to the cost of purchasing the computer systems. Most
likely there would be regular fees for maintenance or necessary upgrading that the company
would have to undertake over the course of utilizing the system. Lastly, since there is no
computer system being used, all employees would have to be trained. This model did not
incorporate how the system may affect kitchen staff performance and communication between
servers and cooks. This may negatively affect accurately preparing specialty customer orders or
decrease efficiency. While these may be serious costs associated with implementing a computer
system, it is up to management whether the long term benefit outweigh the initial startup costs at
implementation.
Sample size 10
Mean(Zj) 0.281
Var(Zj) 1.618
Lower limit -0.799
Upper limit 1.361
alpha 0.1
alpha_hat 0.025
Adding Card Machine
VS Adding Card
Machine and Cashier

16. Kembel 16
Conclusion
As the above sections show, the Provino’s Italian Restaurant dine-in service system has
been sufficiently modeled. The fundamental processes associated with providing service to
customers, efficiently utilizing resources, and moving the customers through the system were
modeled accurately based on data collection and suggestions from restaurant management and
staff.
However, there is an opportunity to continue research and widen this models scope, while
improving accuracy. With significant data collection, estimates on all processes could be more
accurately modeled, as well as the inclusion of other restaurant processes such as cleaning tables
and booths, managing alcoholic and non-alcoholic beverages, and serving bar and to-go
customers. Similarly, instead of only focusing on the customer facing half of the restaurant, the
model could include the full system involved in order preparation by the kitchen staff. This
would include inventory management and prepping efficiency of some menu options. Lastly,
additional research into scheduling of servers, kitchen, and restaurant staff could be modeled to
estimate cost efficiency. All of these areas of investigation will require significant data collection
and consulting with Provino’s staff.
In conclusion, this report suggests that Provino’s pursue the Model 1 what-if scenario of
adding one additional card machine. In comparison to the other proposed models, Model 1 offers
the greatest opportunity for system improvement, at the lowest cost. However, as the previous
evidence suggested, Model 3, the addition of the computer system, will off the greatest potential
for system improvement. Since Provino’s Italian Restaurant maintains a classic Italian restaurant
image, and may desire to update and change all of their check control processes, at a significant
cost, it is recommended the company implement the Model 1 changes to immediately improve
customer Wait time. Lastly, after implementing the Model 1 system, an increase in demand from
customers may create additional system inefficiencies that were not considered in this model.
Similarly, an increase in demand may make implanting Model 3 necessary in order to continue to
improve efficiency and effectively control customer bills.