By Matt Wampler, CEO of ClearCOGS
Plenty of restaurant groups have set up an inventory and recipe system properly. A surprising number have done it twice.
The pattern is consistent enough to describe without embellishment. Recipes entered, items mapped, variance reporting running, everything correct on the day it goes live. A few months later it is roughly okay. A year later it is not accurate, and by then nobody is using it. So the whole exercise gets done again.
None of those are failed implementations. They are successful ones that did not stay true.
The thing nobody puts in the project plan
Here is how it comes apart, and it is almost always the same way.
You buy the same product you always buy, but it arrives as a different item. Different vendor, different pack, different code. The recipe in your system is still pointed at the old one. Nobody notices, because the food showed up and service went fine.
Or the case changes size. You normally order a case of forty eight avocados. One week a case arrives with twenty four in it, at roughly half the price. The invoice says one case. The only person on earth who knows that case held twenty four is the one who opened it, and they are not entering data. Your system assumes forty eight, your cost per avocado silently halves, and your variance on that item goes strange in a way that will take somebody an afternoon to untangle.
None of this is a software defect. The software is doing exactly what it was told. The world underneath it moved and nobody told it.
Multiply that across a few hundred items, several vendors, and a couple of concepts, and the drift is not occasional. It is continuous. Keeping it correct is not a project with an end date, it is a job.
The part that actually kills it
The cost of the drift is not really the wrong numbers. It is what the wrong numbers do to people.
A variance report that was right in March and wrong in September does not get treated as ninety percent useful. It gets treated as unreliable, because a chef who was once told to explain a discrepancy that turned out to be a mapping error will not spend an afternoon on the next one. They will nod, and go back to doing it the way they always did.
Once that happens, the tool is not part of how the place runs anymore. It is a thing accounting looks at. And when someone eventually decides to fix it, the rebuild lands on the same operators who already learned, from experience, that it will be wrong again by next spring.
That is the loop worth naming. The system is not distrusted because it was badly built. It is distrusted because it was correct once, and nobody was responsible for keeping it that way.
The research points at the same thing
This is not a restaurant problem. It is a well-documented organizational one, and the finding is blunt.
Researchers surveying companies about the obstacles to keeping their core reference data accurate concluded that a lack of delegated responsibility for maintaining that data was the single factor with the largest impact on its quality. Not the software. Not staff skill. Ownership. The same work found that the large majority of companies believed poor data quality was doing them real harm, which tells you this is widely felt and rarely fixed (Haug and Stentoft Arlbjorn, Journal of Enterprise Information Management, 2011).
Sit with the shape of that. Most organizations know the data is decaying. Most believe it is costing them. And the main reason it keeps decaying is that maintaining it is nobody’s actual job.
Restaurants are an unusually harsh case, because the thing that changes is the supply chain, and the supply chain changes constantly. A manufacturing company might revise a bill of materials a few times a year. A restaurant group absorbs substitutions, pack changes, seasonal swaps, and menu revisions more or less every week, across every concept.
And the ownership gap is structural. Finance usually drives this work, because finance feels the pain in the variance report. But the information lives with the people receiving deliveries and cooking the food, who are measured on service and labor and food cost, and not one of whom has ever been evaluated on whether an item code points at the right case size.
What actually helps
Four things, and only one of them involves buying anything.
Give it a name. Not a department, a person. Somebody whose job description includes keeping recipes and item mappings current, with time protected for it. If you cannot find that person, you have just learned what your next system will do, which is decay on the same schedule as the last one.
Decide what has to stay accurate. Not everything deserves the same care. The twenty items driving most of your cost need their mappings right. The long tail can drift, and pretending otherwise is how maintenance plans die. Making that call explicitly is more honest than an unwritten policy of maintaining everything and actually maintaining nothing.
Put the update where the change happens. The person who opens the twenty four count case is the one who knows. A process that requires them to tell someone in an office, who then updates a record, has a failure point built into it. The closer the update sits to the receiving door, the more likely it is to happen.
Ask who maintains it before you buy it. This is the question I would put to any vendor, including us. What has to be kept up to date for this to keep working, how often does it change, and whose hands are on it. A system where that answer is “ours” is a different proposition from one where the answer is “a member of your team, weekly, forever.” Both can be fine. Confusing one for the other is what produces the third rebuild.
Most software decisions get made on the demo and the setup plan. The launch is where the attention is, and the launch is genuinely hard, so it feels like the hard part.
It is not. The hard part starts the week after go-live, when the world resumes changing and the person who built everything moves on to the next project. Whether the thing is still true in eighteen months has very little to do with how good the implementation was, and almost everything to do with whether anybody was made responsible for the drift.
So when you evaluate your current stack, do not ask whether it was set up correctly. It probably was, more than once. Ask what has changed since, who was supposed to notice, and what happened to the people who were told to trust it.
This is a large part of why we run things the way we do at ClearCOGS. The recipe mapping, the item changes, the pack size updates: that work sits with our team rather than landing back on your chefs, because a number nobody maintains becomes a number nobody believes.
If your group has set the same system up more than once and cannot work out why it keeps drifting, that is worth a conversation.
Sources
- Haug, Anders, and Stentoft Arlbjorn, Jan. Barriers to Master Data Quality. Journal of Enterprise Information Management, 24(3), 288–303. 2011. doi.org
