The basic idea behind the Kitchen Minder is to inform your employees when to cook product. The Kitchen Minder aims to atticipate how much product needs to be prepared ahead of time to allow your crew to serve food fast to customers, but also reduce waste caused by crew members over estimating demand and cooking too much product. It calculates the quantity of each item to be cooked using sales data from your Point of Sale System. The underlying theory behind the KM system is very appealing, but as of this moment there are some notable short comings.
- Importing your product mix into the PC Minder software is a painful process. If your QSR concept has multiple dayparts, there is a bug in the import process where you have to add lunch items to the breakfast day-part in order to then be able to add them to the lunch day-part. At the end of the process you then need to go back and delete your lunch items from the breakfast day-part.
- The Kitchen Minder software can only communicate over serial connection using COM ports 1-6. When testing the connectivity between the BOH computer and the Kitchen Minder, if you choose the wrong COM port and attempt to send the programming, the software will freeze up for several minutes before it finally gives you a “cables not connected” message.
- The way the product sales projections are calculated is weak. At the beginning of each day you are supposed to import sales data from the previous week into the system. This sounds simple enough, but what happens if last Monday it was raining? or a school bus full of kids ate at your restaurant? This will affect what the Kitchen Minder thinks you should be cooking today. In the real world you will have too many Store Managers working on different shifts for anyone to remember that maybe last weeks data isn’t likely to reflect todays sales.
There is allegedly an update to the software on the horizon that should address points 1 and 2, but I have yet to hear anything about improvements to the sales projections algorithm.
You go, man.
Pls. copy whatshisface w/ BK corporate about the version difficiency we STILL are having w/ GOICC. I’m going to take this up with some other guys a little higher up the chain to see if some other solution is in the works.
Using the sales data from the previous week seems very flawed to me. To me it would seem wiser to figure out the percentage of an item sold per person over a statistically valid period of time. For instance, 58% of all sales include fries, 23% are double cheeseburgers, 8% Fried Chicken Sandwich, etc.. You would also want to calculate the average number of people per order. Then you could have an automated system that would either track the amount of people entering the store with some type of video recognition software and the staff would start to make certain items based on that data. You could also use cameras or metal detectors to determine how many cars are in the drive through. If a new store is being constructed, depending on the layout, metal detectors could be built into the drive ways that would determine how many cars are entering the property (and exiting) and then commands could be sent to the cooks 1 good minute prior to them ordering in the drive thru or walking into the store. Just a thought…