Known Problem, Unknown Solution
A popular and successful restaurant suffered from a well known, long standing problem (literally). We’ve all seen and experienced it; long lines waiting to get a seat in a popular restaurant, even though you can see open seating available. This is an industry wide problem experienced by many restaurants. However, the solution isn’t quite as easy as you might think, unless you like to share your table with total strangers.
Focusing in on the Real Issue
They had a suspicion that the cause of the problem might be one, or a combination, of 3 things.
1. Availability of the food (preparation time)
2. People staying too long after their meal was done
3. Inefficient serving staff
The first thing to do was to sit in the restaurant during peak hours and observe what was happening. They found that in spite of a long line of waiting customers, 50-60% of the seats were empty. This was because many small parties (2 or 3 people) were sitting at tables intended for 4 or more customers.
Table Mix Optimization
They had previously tried adding additional serving staff. But the lines remained long and the seats unused. They also noticed that when customers where at larger tables and there were many empty seats around them, they tended to stay longer since they perceived that there was no rush for them to leave. Something else needed to be tried. But what?
The consultant saw what most everyone else saw, that the mix of table sizes was not effectively accommodating the waiting customers. But with ProcessModel software, he had the tools needed to find the optimum table mix.
The software was first used to create a model of their current situation. By analyzing the data the company had collected about customer arrivals and party sizes, the consultant built a model which yielded accurate results as reflected in their collected data. The next task was to build a model that would allow the system to find the optimal mix of tables to handle their customers more efficiently. Some rules had to be established.
1. Parties of 2 would be seated at a 2 top table whenever possible. However, they could also be seated at a 4 top table, but never at larger tables.
2. There would be no table combining during peak hours because it actually caused delays which lowered customer satisfaction.
3. Based on the results of the model, the table layout in the restaurant would be changed as needed during non-busy time to accommodate for upcoming busy hours.
4. The model would need to be changed from time to time to meet the requirements of new locations or newly gathered data analysis of customer patterns. Therefore, the learning curve would need to be shortened and change procedures simplified as much as possible.
The Model
It was determined that during peak hours, there was basically a continuous flow of customers so the Continuous Arrival was used.
The only change needed in the model to optimize for different locations or using different collected data is the breakdown of group sizes. This is the attribute a_Group_Size and is assigned its value in the “Line for Cashier” storage.
In the action logic shown above, the group size is assigned using embedded User-Defined distributions. 63.23% of the time, group size is either 1 or 2 people. Of that 63.23% of the time, 14.74% of the time the party size is 1. 85.26% of the time the party size is 2. Other group sizes are assigned in a similar fashion.
Then, based on the group size, a time is assigned for how long they will stay, and the ticket size (cost of the meal). The computer resource is simply used to ensure that more parties aren’t allowed into the eating area than there are total tables.
Based on the group size, the party is routed to the appropriate table using conditional routes.
Additional action logic is used to check the utilization of each table size. So if a group of 2 come in but the 2 top tables are all used, the group can be sent to a 4 top table. Only 1 size upgrade is available per party however.
Optimization
Using ProcessModel’s optimization module called SimRunner, the consultant began by indicating his goal was to maximize the number of customers served, while minimizing the total number of tables used. Then, using scenario parameters he had created in the model, he specified a range of possible values for each table size. The system then ran as many experiments (or simulations) as needed to find the optimum number of tables of each size to reach the desired goal.
It is important to note that the optimized table mixes were created specifically for use during peak hours. During times when the restaurant is not at maximum capacity, it is less important to use an optimized table mix as there is no shortage of available seating, regardless of each party’s size.
Your 1st Assignment
The CEO and Chairman of the Restaurant, is skeptical of any changes to his successful chain of restaurants. He has been made aware of your work in simulation and has now requested a presentation from your group. He wants to see proof that you can maximize the number of customers served and increase the revenue for a restaurant. You are only responsible for showing how you can change business during peak hours (blocks of 3 hours). He wants the bottom line:
• How much can we increase our revenue during peak hours?
• What is the maximum number of customers we can serve during a peak 3 hour time frame?
• How do you intend to achieve this goal?
Download Case Study 5 – Restaurant model here.
Install the package file Case Study 5 – Restaurant.
The model is already complete so you won’t need to add any new logic or change the structure of the model. Your first task is to manually create two scenarios which you think will be helpful in reaching the “bottom line” Mr. Overton wants to see.
To create your scenarios, click the Simulation menu and select the Define Scenarios option. Click the New button and name the scenario.
Note the parameter called s_Total_Seats. This is the scenario parameter which sets the maximum number of seats allowed in the restaurant according to fire code. The model is built to not allow exceeding that seating capacity during optimization. So don’t change that parameter value. Instead, change the parameter values for the quantity of each table size. Your objective is to maximize throughput of the restaurant without exceeding the seating capacity, as well as make as much money as you can, and serve as many customers as possible.
Create a 2 nd scenario in the same way and choose different parameter values. Close the scenario window. In order to run your scenarios, click Simulation and select the Run Scenarios option. Compare the results of each scenario to determine how well they performed, which one was best, and how close you came to making the boss happy.
Your 2nd Assignment
Now that you’ve manually created your scenarios and compared the results, let’s see how ProcessModel can make your life a whole lot easier. Use SimRunner to automatically find the optimal table mix for you. You will need the help of your instructor to understand and properly setup SimRunner. So wait for your next class in
order to receive that help. Following that instruction, sit back and watch while ProcessModel does the analysis for you.
SimRunner Setup
Use the following setup details:
1. SimRunner uses the simulation data file created when a simulation is started. Therefore, before starting SimRunner you must start your simulation. It can either be a normal run or you may run scenarios. It isn’t necessary to complete a simulation however. Just start the simulation , then end it immediately. Click Tools / SimRunner. The simulation data file will be loaded automatically.
2. An optimization project file called Case Study 5 – Restaurant.opt is included (click here to download) with the model package. It contains all the parameters needed to run an optimization. To load the project file, click File / Open Project and browse to the folder where the model package was installed and select the project file.
3. The Setup Project button at the top left of the window allows you to create the objective of running the optimization and define the inputs you’d like the system to change in order to meet that objective.
4. Click Define objectives on the left. On the right you will see two variables with the desired outcome for each. The v_Opt_Error variable is assigned a value using the model’s Capacity Trigger and is used to monitor the total number of seats assigned to the table mix scenario parameters. If the number exceeds the maximum allowed, a value of -100 is assigned in the model. If the total number of seats is within the limit, a value of 100 is assigned. Note SimRunner is setup to maximize that variable value and assign a weight factor of 100. So if the simulation run within the limit, the objective function is incremented by 10000. If it is above the limit, a value of -10000 is added to the objective function. There is also a variable being maximized which represents the total number of customers. Since each party size is given a new entity name in the model, the variable is used to calculate the total number of each party size. The goal is to maximize that variable.
5. Click Define inputs. This section displays each of the scenario parameters that were created in the model. These are the values which SimRunner will alter in order to find the optimal configuration. You will see that s_Total_Seats is the only scenario parameter no selected for modification since that parameter is fixed by the fire code for the building. We want the system to alter all other scenario parameters to find the best table mix in order to meet our defined objectives.
6. It is important to note that the larger the spread of possible values for each parameter when defining your inputs, the more possible outcomes there will be. Therefore, the optimization will take longer to run. For that reason, a narrowed set of values has been pre-selected. But if you’d like to change the ranges, feel free to experiment.
7. For simplicity, the model is setup with a run length of 24 hours. That means it will run from midnight Monday morning to midnight Tuesday morning. Arrival information is built in to run longer than that. But this exercise is only intended to optimize one day’s worth of data.
8. Click the Optimize Model button at the upper right of the window. Then click the Seek optimum button on the left. Click Run to begin the optimization.
9. The Performance Plot window will graphically display the results of each experiment (complete simulation run) with the green line tracking the objective function of each experiment, and the red line at the top showing the best performing experiment.
10. The spreadsheet area displays the details of each experiment. The chart is sorted by the best resultant objective function.
11. When the optimization is complete, review each scenario parameter’s value in the spreadsheet. The best performing experiment will be at the top of the chart.
Self Teaching Guide
Getting Started
Lessons
- Your First Model
- Replications and Distributions
- Entity Arrivals
- Routings
- Attributes, Variables and Action Logic
- Shifts
- A More Complex Call Center
- Model Building Techniques
Case Studies
- Analysis
- Replications
- Froedtert Hospital Improves ICU Care
- Nuclear Site Cleanup
- Restaurant Customer Seating Optimization