What Does Food Data Mastery Look Like In A Modern Food Business?
March 13, 2023
Mastering how food data is collected, organized, and managed is one of the highest-leverage activities a food brand can engage in. We’ve entered an era of razor-thin margins, high costs and pressures around every corner, and unprecedented competition. Many of the old ways of creating and communicating food plans—like emailed recipe PDFs and printed production plans—don’t match the speed and clarity our current market demands.
This has been true for a while. We noted before that the companies who modernized their food data management early on fared particularly well during the initial years of the coronavirus pandemic. And it’s only becoming more true. Breakneck efficiency is the name of the game, and food data enables us to get there.
In this article, we’ll explore what food data mastery looks like in a modern food business, including…
The four food data areas (and the exact data points) modern food brands track
How using recipes as building blocks makes for more profitable menu planning
New techniques and tools for collecting and integrating data into one system
The principles and data points we’re going to discuss are not hypothetical. We’ve had a backstage pass to some of the largest and fastest-growing foodservice brands in the world. We’ve seen what’s working, and we’re excited to share it with you.
Before We Dive In, A Few Era-Defining Concepts
Here’s a quick overview of some of the new innovations that are evolving out of our tech-enabled food data era. These are the key concepts that make modern, sophisticated food data management possible.
Culinary Operating Systems — Traditional ERP tools are generally built around accounting frameworks and needs (not food businesses). Food-specific ERPs, sometimes called Culinary Operating Systems, are software tools specifically built to handle the complexities and needs of the food industry. They are ERP tools, in essence, but are built to better-handle and integrate food industry systems, like recipe planning, menu planning, inventory and purchasing, etc.
Universal language of food — Yes, food is the universal language, uniting all peoples. However, food data has historically lacked a standardized format, causing a whole slew of communication problems (like mis-converting “cases” of potatoes to “cups” of diced potatoes). We’re developing a universal language for food that standardizes every data point of the recipe, allowing it to be communicated or translated immediately across any tool or system (for example, connecting POS data to inventory data to vendor pricing data, and beyond).
Real-time vendor pricing — Vendors send prices in a variety of formats. PDF price lists, written email updates, website changes. The most sophisticated suppliers support automated EDI connections. No matter how they receive pricing information, modern food businesses automate its digestion so that all ingredient prices in their culinary operating system are up-to-date in real-time, without someone having to go in and type new prices in.
The key theme here is food data connectivity. Modern food brands do not keep their data siloed in many systems, but collect it all into a culinary operating system so that it can be inter-connected.
This saves countless hours from manual, double-entry of data across software or spreadsheets. It also makes it possible to interact that data dynamically so that, when one data point changes, every other data point it touches also changes immediately (for example, the cost of a case of tomatoes rises $0.23, and the culinary operating system automatically updates the food costs for every dish that uses tomatoes).
Businesses that lean into these principles adopt a recipe-first philosophy to everything culinary. What this essentially means is that every other food system—menu planning, purchasing, production plans, and even financial planning—it’s all made up of recipe data that’s assembled and organized in different ways, then mixed with data unique to those systems. But it all starts at the recipe. If the recipe data is wrong or incomplete, everything is.
How Recipe Data Is Used
Every ingredient in the recipe is assigned a unit and a quantity. Instructions for how to prepare and serve the recipe are attached. For ingredients or cooking processes that produce trim yield (like cutting off the top two layers of onions), that waste can be noted in the recipe as an expected average. Nutritional and allergen information can be connected for each ingredient, then added to with additional nutrition impacts from cooking preparations (like pan searing versus frying).
By connecting the real-time vendor pricing to each ingredient, you’re able to see the cost of each ingredient individually, and all together as the full recipe. If a preparation technique in the recipe creates trim yield, that waste can be identified and the costs calculated for that as well. Adding a retail price data point to the recipe can mean your Culinary OS can calculate your profit margin for each recipe automatically.
Recipes can be nested into other recipes, like how marinara sauce is a sub-recipe in a chicken parmesan recipe. When a recipe’s quantities are scaled, all of the associated data can be scaled in parallel. When an ingredient in a recipe changes, all of the recipe information—the nutritional data, the costing data, the recipe scaling calculations—can be updated instantly to reflect the change.
Once recipes have been built within the culinary operating system, menu planning becomes much easier. Menus can be constructed by adding recipes into the menu plan, and all of the associated data from the recipe is pulled in, at any scale required
How Menu Data Is Used
Menu planning, to oversimplify things, is a matter of estimating demand and then creating a package of recipes to satisfy that demand with as little over or under-production as possible. Data-driven food companies follow the same core steps to accomplishing this, but once they start handling recipes, planning becomes much more efficient.
Sales forecasting is the starting place. Once an estimate is established, menu planners can select recipes to include in the menu, then scale them as needed. In an interconnected culinary operating system, all of that recipe data—ingredients, costs, allergens, everything—is pulled into the menu plan automatically.
One great advantage of this is that the real-time recipe costs can be seen at the menu level. If making one margherita pizza costs $6.41 to make in COGS, the menu planners can see that, at 300 margherita pizzas on the menu, the COGS rise to a total of $1,923. If mozzarella prices skyrocket due to a shortage and cause the margherita COGS to rise to $7.02 ($2,106 for 300 pizzas), the menu planner can see that impact automatically (+$200 in costs!) and evaluate whether the recipe should be pulled from the menu temporarily, or the price of the pizza raised.
Another way brands use this is to better track and organize nutritionals and allergens. Many food planners do not have menus connected to updated recipes, so there’s a large amount of “chasing” that happens to ensure the right allergens are labeled and tracked, and that there are always recipe options for specialized diets, like paleo or gluten-free. In modern culinary operating systems, that metadata tracked in each recipe added to the menu, so planners are able to easily and accurately count those instances of allergens of diet-friendly recipes as they create the menu.
Purchasing and Inventory Data: Getting Everything You Need
Once recipe data has been aggregated into the menu plan, there are two systems—inventory and purchasing—that have to work in lock-step to make sure you have everything you need to execute on that menu.
How Purchasing and Inventory Data Are Used Together
The inventory system’s main goal is to understand what the food business already has in stock. The purchasing system wants to order any extra food that’s required to fulfill a menu. In many food businesses—even very large ones—this relationship is oversimplified: a person takes inventory, makes a note of what’s in stock at that moment, then whoever is responsible for purchasing looks that that number, subtracts it from the total food needed to meet expected demand, and places an order for the remaining needed food.
There are a few faults with this approach. Food inventory is not static, and some amount of spoilage is guaranteed to take place. If a purchaser makes an order based on today’s inventory, and not the expected inventory of two days from now, when the order actually arrives, they may be surprised to find that the inventory numbers are no longer true now that a percentage of the food has spoiled in that time (and thus, the recent order is no longer enough food to satisfy expected demand).
Another drawback is that it’s not always clear what food in stock has already been committed to be prepared or cooked. If you’re a restaurant counting 50 cases of tomatoes, but you will have to pull 5 cases of tomatoes later in the day to serve the dinner rush, you don’t really have 50 cases of tomatoes able to be managed and planned around—you have 45.
We’re seeing modern food brands take a more sophisticated approach that’s only just now possible through interconnected culinary operating systems that can understand real-time inventory, and layer a whole bunch of data points on top of it (expected shelf life, inventory in transit but not in stock, and inventory that’s already committed).
With this richer data, inventory systems have a full view of how food travels and is used within the business—and that gives the purchasing system a huge amount of power to be more efficient. Rather than relying on static cycle counts that don’t show the whole picture, purchasing teams can order food so that the kitchen teams receive the exact food they need, right when they need it.
Food Production Data: Where The Rubber Meets The Road
The food production data is the bridge between food planning and food preparation. This is where the theoretical recipes and menus of perfect plans turn into actual recipes and menus through the beautiful, error-prone work of human hands. And tracking that theoretical-actual difference is crucial to understanding how efficiently a kitchen operates.
How Food Production Data Is Used
The commercial kitchen is where the magic happens. It’s also where things are least predictable. Food goes missing or spoils faster than expected, tired employees begin prepping food in non-optimal orders, and someone forgets to account for a recipe when batch-producing the marinara sauce. Mistakes and misunderstandings are inevitable, but modern food brands lean on objective data to smooth over and outsmart them as much as possible.
A common practice in the industry is for a back-office planner to send kitchen teams a list of recipes they’ll be creating for that day/week. The team then pulls out the recipes from a physical binder (or loads up a spreadsheet) and someone manually orders the prep and cooking tasks to cut out redundancies and make sure everything gets prepared in the right order.
The problem is that, when you’re eyeballing a list of recipes, ingredients, and cooking processes, there’s only so much you can keep track of in order to make a production plan. You’ll likely spot that the biscuitsand gravy and chicken fried steak both need gravy to be produced, and can batch that out. But you may miss that the scalloped potatoes and catfish courtbouillon also include roux in the recipes. This is a missed opportunity to batch-make the roux, then divide it between gravy and other recipes.
Sophisticated culinary operating systems don’t cross their fingers and hope a human can see opportunities for batching, or proper task ordering. Instead, since all of the recipe data is built into the menu plan, a production plan can automatically be created showing exactly how much of each recipe needs to be created and batched, and in what order. This removes opportunities for human error in getting the day’s operation going.
Savvy culinary teams are also carefully monitoring data points that are not commonly measured in commercial kitchens: actual trim and waste, and actual cooking time. Most teams already have general estimates for how long tasks take to complete and how much food is sent to the trash bin. By precisely measuring how long it actually takes—not relying on those estimates, accurate or not—culinary teams are able to spot inefficiencies as they arise.
For example, a sudden increase in food waste can now be spotted objectively, enabling managers to investigate the cause. This could be a new employee who’s still a bit sloppy on prep, or it could be a food safety error that leads to extra dishes being thrown out before reaching a customer. In the same vein, measuring the time it takes to complete cooking tasks enables kitchen managers to spot areas that are running slower than they should be.
The New Reality: Great Food Businesses Are Data Businesses
In our new era of non-negotiable efficiency, food data is not a nice-to-have set of numbers in a rarely-seen dashboard. It’s the magic weapon that gives culinary teams powers they’ve never been able to have before.
And it’s within reach for food companies of all kinds and sizes.
Galley Solutions is a recipe-first culinary operating system that gives food companies complete power over their food data. We built a platform that connects all departments and all data—recipe planning and costing, menu planning, inventory and purchasing, and production—into a central hub. Here’s what it means for our customers:
Real-time vendor, costing, and operational data that enables rapid decision-making
Fast collaborative R&D, with streamlined pushing out of new recipes
Full supply chain inventory visibility and tracking
Automatically-created purchase orders based on inventory + menu plan
Automated production guides that find the best ways to scale recipes, batch cook, and order tasks
Food businesses that collect, organize, and learn to command their data have a bright future ahead—we’d love to help show you how
The rich text element allows you to create and format headings, paragraphs, blockquotes, images, and video all in one place instead of having to add and format them individually. Just double-click and easily create content.
Static and dynamic content editing
A rich text element can be used with static or dynamic content. For static content, just drop it into any page and begin editing. For dynamic content, add a rich text field to any collection and then connect a rich text element to that field in the settings panel. Voila!
How to customize formatting for each rich text
Headings, paragraphs, blockquotes, figures, images, and figure captions can all be styled after a class is added to the rich text element using the "When inside of" nested selector system.