operations simulation

(fall 2022)

WHAT IS IT?:

As part of MIT’s 2.854 Intro to Manufacturing course in Fall 2022, my team of 3 designed and executed a discrete event simulation for restaurant operations, using manufacturing line principles analogous to the process.

Our goal was to determine the optimal reservation schematic in terms of percentage of tables allowed for reservation, understand the flow of people (demand for product) throughout a week, a month, and over seasons. We collaborated with a local restaurant in Cambridge, (Viale) to gather data and tailor our recommendations.

PROJECT DETAILS:

In the dining industry, it is typical for restaurants to operate on very thin profit margins due to high overhead costs – kitchen machines, capital, facilities/utilities, staff and labor costs, and raw product costs which are alway trending higher, even though the external menu pricing cannot inflate proportionally due to customer satisfaction risk. Thus, a restaurant needs to maximize revenue to maximize this profit margin. One of the key parts in the front of house optimization is understanding the best reservation logic and schema to allow for maximum profit between reservations and walk-ins. To help this maximization, a discrete event simulation was built and executed over 10,000 nights per weekday, specific to a local Cambridge restaurant, Viale.

Targeted outputs were to determine what the optimal reservation schema was for percentage of tables allowed to be reserved, and additional restaurant optimization suggestions such as seating configurations.  It was discovered that allowing for all the tables in the restaurant to be reserved, specific to Viale, was optimal, and it was suggested to reevaluate table capacities as there is more build up of parties of 5-8 in the queue over high demand nights due to all parties of 5+ trying to be seated at a limited number of tables with sufficient size in a night. In addition, the simulation was stress tested to see if there were optimal schema for scenarios where Viale may have 2x increases in demand, as well as used to test the current nominal scenario to compare revenue data to real time data. Data compared was found to have agreed well with simulated values (within the same order of magnitude).

The simulation was executed based on many assumptions to reservation logic as well as event flow of a night, and only captured behavior for a short segment of the fall 2022 season. Future work would include improving the granularity of the simulation to capture more reservation cases, seasonality trends, back of house dynamics, and a better capacity to handle the unpredictability of how humans behave in queues or how they react to wait times in real time.

ROLE:

Once data was collected from Viale, we needed to scrub the data in a manner that we could easily glean distributions and pass them into python as a csv to do our functions on. I helped with this data gleaning.

For our actual Restaurant DES Simulation code, I was in charge of the reservation algorithm. Given a times array and a part size array that correlated to reservation requests (randomly generated for a day based on observed distributions from Viale), I made sure that the algorithm could check if enough tables to fill the size request for the requested time were available. If so, then it booked that table for the amount of hours according to Viale’s set party size and dining time scheme (linked in our drive submission). If not, it would look for the next nearest dining time where tables of the size were available, either earlier or later, and book the party for then. If none of those, then the algorithm would return an empty reservation array output for that request, and return “did not book”. Different party sizes required slightly different table checking logic, ie: parties of 1-2 need to only check for tables with capacity 2, 3-4 tables with only capacity 4, 5-8 tables with capacity 8, and 9-12 would check for both a table of 8 and a table of 4, and then 13+ would check for two tables of 8. Ultimately I had to make 4 separate functions for this. So I made some assumptions that simplified the functions here, didn’t allow for pulling up extra chairs, or like a 8+4+2 table configuration to make room for 14 people. 

Next, I help pass the final reservation events array once all parties for the day could be booked, into our actual simulation that pulled events for the night and such. After the code was integrated, I helped debug and troubleshoot to get a fully functional simulation.

On the logistics side, I did a lot of coordinating with potential partners, sent out a bunch of emails/visited restaurants to scout them in the beginning stages of the project. I created the Gantt Chart, project report outline and proposal outline, managed and consolidated the slide deck amongst teammates.

SKILLS:

• operations

• discrete event simulation (Python)

• project management