Some friends and I have been spending the past 4 weeks thinking about how restaurant inventory tracking works. As a consequence I've been having lots of conversations with restaurant owners and operators trying to better understand the problem of tracking inventory, shrinkage, and measuring current inventory. The process has been interesting; this is a summary of what I've learned so far.
First, there are a few concepts that helped me understand the problem space:
1. Shrinkage = Initial Inventory - Sold Inventory - Current Inventory
Initial inventory and sold inventory can be tracked through the vendor order and your POS system data, respectively, but your current inventory count is harder to track.
2. "Balance Sheet" Food cost % = (Initial Food Cost - $(Current Food Inventory)) / Sales
I'm calling this "Balance Sheet" food cost % to distinguish from "Cash Flow" food cost %, which would take the net food cost over a period of time and divide it by the net sales over the same period. The former is a 'snapshot' in time, the latter is an average over a longer period.
3. Re-Order Inventory = "Par" Inventory - Current Inventory
"Par" inventory is a set level of inventory to keep on stock at a given time. Typically static, this value can change based on projections of sales (eg, if greater foot traffic is expected because of nicer weather, the restaurant may want to set higher par values for that period).
Imagine the landscape of restaurants as a line, shown below:
As you move along the line inventory optimization becomes more important and the operational problems get harder. I heard feedback that 3 important events occur as you grow: opening a second location; inventory costs cross a line that tracking shrinkage becomes a burning need; and sales grow enough to justify building a total custom inventory tracking solution.
Starting out, a single location restaurant can track their inventory mostly by paper / on a computer relatively easily. Calculating 'balance sheet' food cost and placing reorders are the primary concerns, shrinkage is less of a problem. Most shrinkage can be managed through the owner/operator's personal supervision.
When you get the second location, suddenly inventory becomes abstract. You need to rely on someone else to tell you what your current inventory is at the other location. This is required for order placement (need to know what current inventory is to know what to restock against a projection of sales for the next period) and tracking things like shrinkage (less important). iPad with a google doc spreadsheet is a pretty good solution here. Getting your shrinkage is "another data point" that's nice to have, but not yet urgent.
At some point your sales will be large enough that it will make sense to focus on managing shrinkage down. This has now become a burning problem, not a 'nice to have' optimization. As current inventory is tracked and gaps emerge between expected inventory vs. reality, management needs to happen on accurate portioning, theft prevention, safer handling to avoid spillage, etc. More accurate understanding of current inventory is more important, so weighing some inventory vs. counting may be preferred. This person wants something that works "like the minibar in Las Vegas" (close to real time insight into when inventory is consumed and in what amount).
Eventually your sales are large enough that it makes sense to just build your own proprietary solution to better track and manage inventory for more accurate reordering and shrinkage tracking. If you're a big national smoothie chain, for example, you may have a scale connected to the internet that you wheel out and weigh all your fruit containers, ice cream, etc. each night, and the data from this tracking (along with original order information and POS data) is collected back at HQ. A more middle-ground solution might be paying someone like Crunchtime to build a custom version of their software for you.
What could a good solution look like?
The most opportunity probably exists at the 'burning problem' level. A good solution for this owner would gather the data of current inventory as close to real time as possible, and has access to the vendor data (original inventory) and the POS system (sold inventory). It should be flexible to support weighing or counting where it makes sense -- the more things that can be weighed, the more accurate the output. Ideally it would also help with reorder (simplistically refilling inventory to pre-defined par level; more sophisticated solution may help predict projected sales for the next period and adjust par values).
To get current inventory levels counted close to real time (without figuring out how to put a scale under everything) you need to build a sufficiently optimized workflow tool that drastically shortens time-to-count while maintaining or increasing accuracy, thus allowing for more frequent and accurate counts. Partender is an example of this workflow optimization applied to bars working well.
For restaurants this solution would be dependent on weight (for accuracy) and fast-search (for speed).
A hardware strategy could be packaging passive RFID tags into daydot stickers (stickers used to keep track of perishable information) and selling a wifi scale that has an RFID reader. BLE would be another route, if it were less costly, to tag the containers. Once set up, you could imagine the workflow going down to seconds per container weighed (as you place the container on the scale and it registers, it could be as fast as checking out from the grocery store).
A software solution might be simple streamlined data entry tool, a little more streamlined than the excel-data-entry-on-an-iPad solution. Simple features like working well on an iPhone with one hand, the ability to quickly 'tap' to enter count information, instant search, and creating a to-do workflow might be enough to push time-to-count down enough to justify counts more often.
We created a 'design draft' of what the software product for this could look like: http://signup.getcosmic.com/
Other thoughts
1. It seemed like everyone needed to predict future sales to determine par, but were all using their own systems that varied in sophistication. If you had an algorithm that looked at future events like weather and sporting events (for foot traffic) along with historical sales, I bet you could create a product here.
2. Interacting with large food vendors (like Sysco) is a mess. Lots of PDFs in e-mails, opaque pricing, re-orders are a nightmare. There is definitely an opportunity in fixing this process.