i need a writer to make a presentation for me
saba998
IE468ProjectReport12.8.18.docxSouthern Illinois University Edwardsville
Executive Summary Report
SIUE MUC Cafeteria Simulation
IE 468 – Operations Research Simulation
By:
Ethan Kasen
Charlie Garrison
Ahmed Alqahtani
Due: December 10, 2018
I. Problem Statement and Objectives of the Study
In this project we are tasked with building a simulation model of Southern Illinois University Edwardsville’s cafeteria. The University struggles with frequent complaints from students and staff about long wait times in the cafeteria. Since students and staff only have little time to break for breakfast, lunch, and dinner, the cafeteria needs to be running in an efficient manner. The University has tasked us with finding the most economic and effective way to cut the average total time in the system by 15%. There are many ways of cutting down time, like improving the process, adding more resources, or cutting out bottlenecks. While there are easy ways to improve average total time, like adding more cash registers or employees, they are not economical for the University. We were able to come up with some very efficient and economical ideas for the school that should make students and staff very happy.
II. The As-Is System: Layout and Entity/Process Flow
The cafeteria is located on the bottom floor of the Morris University Center. There are two sections of the cafeteria, Center Court and the Cougar Den. Center Court has 6 vending options: Entrees, Sammiches, Boss Burgers, Wok, Side Bar, and Chick-Fil-A. Cougar Den has two more dining options, Pizza Hut and Cocina. The first step of any person that walks into the cafeteria is deciding which section to go to, either Center Court or Cougar Den. They will then walk to that side of the cafeteria and decide which dining option they want to have. We have built in process times for both walking to the restaurant, as well as the decision time. You can see this below in Figure 1.
Figure 1: Enter MUC
Once the person walks to the dining option they want, they can order or grab whatever they want to eat. We built in process times based on each dining option. These were carefully calculated based on data taken during the data collection period. This seems to be the bottleneck of the system. We noticed that sometimes food may not be ready, sometimes it may take a long time to cook the food to order, or people can just be slow at ordering their food. This is one of the things that we took into consideration when designing our new model. You can see this in Figure 2 below.
Figure 2: Decide and Process Times
The next step in the process is when the person decides if they want a drink. If they do not want a drink they can walk to the cash registers and begin the checkout process. If they would like a drink, they walk to the drink stands and can grab a soda/water. After that, the person walks to the checkouts and pays for their meal. Once the person has paid for their meal and leaves the cash register, they are declared out of the system. You can see this in Figure 3 below.
Figure 3: Drinks and Exit
III. III. Data Collection, Curve Fitting, and Assumptions
One of the most important aspects of this project is the data collection step. You cannot create an efficient simulation without accurate and complete data. We took this into consideration when we collected our data and ensured that it was reasonable and quality data. We made sure we visited the MUC at all different times of the day and on different days of the week to take data. We tried to gather as much data as possible by studying each dining option in the MUC. We took 100 service times for each dining option. This helped us find a good average time for each restaurant. We also took about 200 data points for the spread of where people decide to eat. We came up with a percentage breakdown for each dining option. Lastly, we took 100 process times for the checkout process. You can see the average breakdown of the average, minimum, and maximum processing times for each station below in Figure 4. You can also see the percentage breakdown of the dining options in Figure 5 below.
Figure 4: Processing Times
Figure 5: Dining Option Breakdown
The arrival data was the hardest to gather since we could not count the total number of people arriving at the MUC all day. We took quite a few samples watching for an hour here or an hour there. We also interview a couple cashiers to get their opinions on how many people come through each day. We decided that the most amount of people visit during lunch time, followed by dinner, and then breakfast. We also found that Monday through Thursday are busiest days, followed by Friday, and then the weekend. We used this data and assumptions to build our model and schedule arrival times.
It is also very important to make valid and correct assumptions so that the model is able to run and is an accurate depiction of the cafeteria. One of the main assumptions that we made is that the process times are going to be similar throughout the entire day on each day of the week. We made this assumption because there are more people working during the busier periods, so lines should move faster because of these extra employees. We also made an assumption on decision time. We did not want to bother people and ask how long it was taking to make an internal decision, so we based the decision times off our own personal experiences. Most of the time the decision is already made before you even enter the system. One last assumption we made was actually a simplification of the schedules. Some of the dining options are only open certain days of the week and will close for a half hour in between meals. Some are even open for lunch one day, but not the next. We made simplified versions of the schedules for simplicity and effectiveness. Without doing this, the simulation was not able to run and kept getting overloaded.
IV. IV. Modeling, Programming, and Animation in ARENA
ARENA is a discrete event simulation and automation software developed by Systems Modeling and acquired by Rockwell Automation is 2000. It uses the SIMAN processor and simulation language. It is the software that we used for the entire course, and what we used to build our model. The model starts with entities being created using a schedule. A greater amount of entities is created during the busy time of the day, and fewer arrive during the abnormal eating times. The entity will follow the path till it reaches the first decision module. Decision module 1 has the entity decide whether it wants to eat at the Cougar Den or Center Court. If an entity goes to the Cougar Den, the entity then has to decide between tacos or pizza. Pay stations and beverage purchases are taken care of in one place in the Cougar Den area. Going to the Center Court is a different story. Entering the Center Court, the entity is faced with a decision module; the entity can select from one of six options (Wok, Chick-fil-a, Sammiches, Boss Burger, Side Bar, and Entrees). The third decision module is then encountered. This decides whether or not a drink is purchased. If a drink is purchased, then they walk over, get a drink, and head to pay. With no drink purchase, the entity goes straight to the checkout queue. Once the entities are done paying they are then released to go eat lunch. The animation was created using the plan for the MUC accessible online and using the drawing tool to add the station and paths in the desired places. Using those tools, we were able to create a model that resembles a day in the MUC. The animation is a very accurate depiction of the MUC. The entities are shown as human beings traveling around the cafeteria, just like in person. You can see a picture of our simulation in Figure 6 below.
Figure 6: Animation
V. Verification of Program and Validation of Model
One of the most important things after building your simulation model is the verification and validation of the model. Verification is concerned with building the model right. It is making sure that the model is implemented correctly in the computer and making sure the input parameters and logical structure of the model are correctly represented. One of the ways we verified the model is by all three looking at it in-depth and making sure the flow is logical and every possible action is implemented in the model. We also wanted to make sure that the model was reasonable under a variety of settings. One of the ways we did this is by interviewing a few MUC dining employees and some of the cashiers to get their opinions. They work there every day, and who knows dining services better than the employees there each day. We told them our ideas for the project and got their input to make sure our model was reasonable and accurate. They agreed that our model was very accurate and should give a good conclusion.
Validation is concerned with building the right model. It is utilized to determine that a model is an accurate representation of the real system. We were able to run our model and compare it to the real system to make sure it was a good representation. It closely matched the arrivals, process times, queues, checkout times, and overall average time of the real system. We did go through a couple revisions from the first model as we moved on. One specific revision we made was cutting back on the number of people entering the system. Not only were we getting a “over 150” error, but we also wanted to make it very close to reality. By the time we made it the last revision, the process was very accurate and judged to be acceptable.
VI. The To-Be System(s)
Our main idea for improvement is a pre-order system, that involves the use of an app or kiosk. The student or staff member would place the order on the app or kiosk. They would still have all the dining options available as well as order variations they can select. These variations could include what type of salad you want, no cheese on a hamburger, or extra french fries. They would then have option to pay on the app or kiosk, or pay in person when they arrive. This is a very good idea, and we decided to base our new model of this concept.
In this new system, there is a create module that creates the customers entering the system. The next come to a decide module that decides if the customer is going to use the app on their phone or the kiosk in the MUC. They are then able to place their order and have the option of paying on the app/kiosk. There is a wait time thereafter, in which their food is prepared. They can then pick up their food at a station in the MUC. If they have not paid yet, they can move on to the pay station. After, the entity exits the system. You can see how this will drastically cut down on time spent in the cafeteria. You can see a flow in Figure 7 below.
INSERT SCREENSHOT OF FLOW
VII. Experiments and Output Analyses
VII. VIII. Interpretations and Recommendations
Some of the other simpler ideas that we came up with were things like achieving shorter processing times and shorter checkout times. We noticed specifically that Chick-Fil-A ran through food on timers throughout the day rather than basing it on busy meal times. For example, they may cook a batch of their most popular item, Spicy Chicken Sandwiches, every 20 minutes, rather than making sure they had more available during meal times. This would cause quite long queues of people waiting for Spicy Chicken, sometimes up to a 6-minute wait. If they had more of the popular items available and ready to go when there was going to be a rush (i.e. 12:15pm on Tuesdays when everyone’s class ends at the same time), this would cut down a lot on processing times. Another idea we came up with is getting rid of the fountain soda machines. These take much more time than just grabbing a bottle of soda. Lastly, we came up with a great idea for faster checkout times. Many stores these days offer touch pay, or Apple pay. If the MUC was able to offer this, it would not only speed up checkout lines, but it would be much more convenient. They could even implement a way to have the cougar card on touch pay.
There are many changes that SIUE could make to the MUC to speed up total time in the system. We believe that our idea our creating a pre-order app is the best way to do this. It will not only speed up times, but we also believe the quality of the food and the happiness of the customers will be greatly improved. We believe that this was a very good project that helped us grow in our simulation creating abilities. There were many concepts from the class that we were able to implement in this project. It is also a very realistic project, and could be very similar to something we need to do in the future in our real-life careers. This project helped us learn a lot and was very useful for our paths going forward.
Processing Times (seconds)
Min Sammiches Boss Burgers Chick-Fil-A Wok Side Bar Entrees Cocina Pizza Hut Checkout 60 118 90 40 81 63 39 30 31 Average Sammiches Boss Burg ers Chick-Fil-A Wok Side Bar Entrees Cocina Pizza Hut Checkout 183.41797872340427 212.87765957446808 255.16521276595742 117.82882978723404 189.35010638297871 157.74148936170212 160.86670212765958 144.79946808510638 83.080957446808512 Max Sammiches Boss Burgers Chick-Fil-A Wok Side Bar Entrees Cocina Pizza Hut Checkout 325 345 400 195 304 243 297 249 300
Dining Options Decision Breakdown
Sammiches Boss Burgers Chick-Fil-A Wok Side Bar Entrees Cocina Pizza Hut 5.4054054054054057E-2 0.12432432432432433 0.21621621621621623 4.3243243243243246E-2 0.16216216216216217 0.14054054054054055 0.10810810810810811 0.15135135135135136
11
