Fix Your Data Where It's Born

Lightly edited for clarity. Solo episode: Ysi Gonzalez, Vantelira.

This episode is powered by Vantelira. We go inside a scaling operation, fix the process, and build the system that keeps it running.

One of my favorite things to work with and decode is data. You need good data to make good decisions, and this applies to product, to software, to services businesses — any industry. Today I want to talk about how, inside an operation, data gets gathered, or should get gathered. Let's dive in.

I'm Ysi, and this is The Forward Deployed Operator. I hope you have your coffee with you, because this is going to be a very interesting talk about how data is not necessarily appropriate when we need decisions taken that will impact a business. Any business size, it doesn't matter. Everybody needs data.

Several times in my career I have worked for companies that produce physical product, and I have done a lot of inventory planning throughout these years. We do inventory planning for decision making: how much investment a company needs, how much inventory we are going to keep, which means how much space you are going to have to plan for. There are several decisions tied to inventory planning, and I want to go back to exactly where that planning starts.

To get those products made you normally need something we call raw material, or components, depending on the stage they are in. Now imagine that to produce your finished product you need different components and raw materials. Depending on what exactly you are producing, you might need ten, twenty, thousands of parts, in different quantities, at different stages. They are sourced from different suppliers. They have different lead times. Those suppliers also have different contact methods, and so on. I could go on forever, because there is so much to unpack there — data points that get mingled and mangled and would need some clarification.

But I want to concentrate on one specific question. How do you know exactly what to buy? Well, you need to make a plan of how much you are going to produce, and that plan needs to be pretty close to your sales. Enter the sales forecast.

There are a lot of people who do not like forecasts. They don't trust them. And the first thing I want to clarify, for everybody to know: forecasts are not 100% accurate. If your forecast is 100% accurate, something is wrong in your calculation. Forecasts are done to give you an idea of how the business is going to perform, so you can have a pillar to stick your plan to, to stick your inventory to, to stick your sales performance to. Of course we work to make the sales forecast as accurate as possible, and it will have a lot of massaging and a lot of decision makers chipping in. But you need to understand that forecasts are not 100% accurate. Once that's clear, then you can move on to how to build one.

So, going back — we're talking about product-based businesses here, where we need to plan for inventory, which means you need to understand how much you are going to produce. And that trickles all the way back to how your sales are being captured.

Where are your sales coming from? Are they coming from different sources? Are they formatted in the same way? When you added a product last year, or two products, however many you added, you may not have given it a proper identifier, or it was not categorized the right way. There are many different stages where data can get broken, and it will result in an improper sales forecast — hence, not a properly planned inventory.

And we call it inventory. Inventory can be, in a real estate environment, assets: your inventory of apartments, the buildings you have, the units you have. In a clinic it's the inventory of beds available for the ICU. And then the sales forecast is what's going to come in to fill those specific units.

So what do you do when your sales are coming from different platforms or different sources of data? What do you do when this data is not properly formatted? How do you connect the dots?

This is where I come in. A Forward Deployed Operator embeds in your organization, and we understand and untangle the spaghetti of how your operation actually runs. Then we plan the cleanup, the design; we measure, we analyze, we improve. And after those first steps we establish control measures so it can run on its own.

That one missing identifier — if you didn't give it a name, an SKU, a proper identifier, a nomenclature that everybody understands — it's never just that. Oh, we didn't have an SKU for this product. That trickles down to sales that were not captured, inventory that didn't get planned. You will end up with an unsatisfied customer, and we don't like that. For a business to grow you need satisfied customers. This is what makes you scale, and it is the very basics of revenue-driven organizations.

This problem doesn't care how big you are. I've seen it in a founder's five spreadsheets, and I've seen it in global enterprises running three different platforms and an ERP that doesn't necessarily communicate with all of them. You can have it in scaling large organizations that recently acquired other companies, and they all have different ERP systems feeding data to a warehouse that nobody really fully understands or trusts. The scale changes, but the shape of how you fix it doesn't.

That one product you didn't identify ends up living under a different name in every system that touches it. One name in the storefront, or the order desk, or the order management system, and another one in the back end — the ERP, the one used to plan inventory, to plan capacity, to plan allocation of resources. It's an abbreviation somebody typed into a regional spreadsheet. A legacy code in the finance export. I'm telling you, it could be a hundred different breaking points. Whether it's four tabs or four enterprise systems, the result is identical: several names, one product, and a forecast that has no idea they're the same thing.

So you go to answer the simplest question in operations. How many did we sell last quarter? And you can't. You can't, because you don't have the right data. Not because you don't have data at all — it's because you haven't cleaned it up. You haven't attached each system to the right SKUs. You have too much of it, in too many shapes, sitting in too many systems that were never designed to agree with each other.

Add channels. Add currency. Add returns, bundles, samples. The order that got entered twice, the acquired business unit that codes this product in a completely different way. And you start to understand why so many forecasts are, to put it kindly, fiction — and why nobody really trusts them.

Now, this is the moment where a lot of people and a lot of organizations reach for a tool. If they don't have a Forward Deployed Operator working with them, or somebody who is really process improvement and continuous improvement driven — meaning we look at the source, what is the source of this problem. There are different methods based on Lean Six Sigma methodology that can help identify where the problem is really coming from. Not what you think it's coming from, not what the symptoms are showing, but really understanding what the root cause is.

And if you don't have that, normally you will reach for a tool, for software. That looks different depending on the maturity of the company. A founder will buy a forecasting app. A mid-market company stands up a demand planning module inside the ERP system they already have. An enterprise commissions a data lake and a six-figure analytics platform. Different budgets, same instinct — and it will be the same trap.

Because if you point a smart tool at data that doesn't agree with itself, you don't get a smart answer. You get a confident wrong answer, faster. And now it's just wrong at scale. Garbage in, garbage out. I learned this about twenty years ago, going to university studying industrial engineering. It is garbage in, garbage out. The first thing you have to do is clean up your data. Otherwise it just creates a bigger license fee.

So when I come in, I don't start with a tool. I start with a shovel. Process before tools. I call it Process Archaeology. You follow the data back to where it's actually born before you automate or integrate a single thing.

And that discipline is the same whether I'm sitting next to a founder or inside a manufacturing plant that sources hundreds of millions of components. I've done both. The questions do not change. And there are three of them that I ask over and over again until I get the right answer. Where does each number come from? Who or what system touches it before it reaches the sales forecast? And which version is the one we all agree to trust?

Because that also happens a lot. There is a sales forecast produced by a team, and then it gets transferred to another team. It could be a person, it could be five people. It gets massaged. It gets presented. Everybody agrees on it. And then it gets massaged again. And when I say massaged, it's really just modifying numbers here, numbers there.

That last question — which version is the one we agreed we were going to trust — is the biggest one. And it's really a question about your system of record. You have to name one place that is the truth. Version five, version seven, whatever it is, everybody signs up. For an early-stage brand, that might be the commerce platform. For a mature organization, it's the ERP governed by real master data management. Either way the principle is identical. Everything else — other channels, other regions, other systems — maps back to that source where you said it was going to be living. Not stored in parallel. Map back, reconcile, one version that wins.

Then you build a boring, unglamorous thing that quietly saves the whole operation: clean master data. And I've done it. It's crazy how in twenty years working with product, service, software — it doesn't matter what you're building, what you're selling — clean master data is the one thing that can break everything.

Every product needs to get one identifier, one definition, one owner. In a small business I say it simply: no SKU, no sale, no exception. In an enterprise it has a fancier name — item master governance, a data ownership model, an onboarding workflow that creates that product consistently across every system before it can be transacted. There are even SOPs or documentation on how the nomenclature of the SKU needs to be produced every time you introduce a new product to the market. There are product management people for this. Same rule, but more rigor, because at scale an ungoverned identifier doesn't create one bad row. It corrupts every downstream report that rolls up through it.

And I have a funny story. I remember working at an enterprise once, and there were different SKUs for the same product. Normally there are processes established where the two SKUs need to have a translator — so in the ERP system being used, you have your current SKU, and there's a field that gets populated with the equivalent SKU. Well, it happened that that SKU did not have that information. Somebody forgot. There was a mistake. It happens. These things happen all the time. But we were able to catch it, because there was a master data governance team looking through all of this data.

We got an order from a customer. The customer was asking for the SKU that was not populated in the field. So in inventory that SKU was showing zero, and the customer service person told the customer, sorry, we don't have that in inventory. And the customer started calling other people, reaching out, until for some reason the email got to me. I was leading the supply chain organization at that point, and I was kind of the police of the inventory — sorry to say it that clearly.

I had to go back and understand what happened. I traced back the story of that SKU, and I ended up discovering that the old SKU was never populated on the new one. We did have it in inventory. It was normal that we were not going to have the old one, so to speak, because we were already transitioning to the new one — but we didn't want to lose sales, so we left the old one active for customers to order. In theory the master data team should have entered the old SKU into the new one, so when the orders came in it would get translated automatically.

So we discovered it was a quick fix. We fixed the system and we told the customer, here's your product, we're going to get it shipped expedited for you — that way the wasted time we spent looking for the answer gets washed off. The customer was happy, walked away, and we made sure the SOPs indicated that information for when other products were going to get outdated or taken out of commission.

And if you're listening and you have a small business, you might think: oh my god, why didn't they just walk through the warehouse to see if they had the product, or a similar one? First, some people don't have the luxury of having their warehouse where their offices are. There are 3PLs located all the way across the country, distributing to where the customer base is. And in other cases it is such a large organization that you cannot just walk out to the warehouse and look for the part. There are thousands of SKUs with thousands of units in them. This is why it's so important to have somebody who understands how things work and can trace back to the root cause of what happened. That SKU was not properly identified.

Once your sources speak the same language — after we fixed that SKU that didn't have the right replacement information — every product should be exactly one thing everywhere. Everywhere it appears, it needs to be the same thing. And if products were superseded or decommissioned, however you want to call it, they need to have that information in them.

Only then can you build a proper forecast. Because that SKU — if we had said to the customer, no, we don't have that product, or we had sold it under the old SKU — we might not even be tracking that old SKU anymore, because it's superseded. We don't see it. But you need that translation, so you can transfer those sales to the new SKU, which might have zero sales in theory because nobody was looking for the new one.

Now, when you tell procurement what to buy and when, you're standing on data you can actually defend. Once you have your translation properly done, your data mapped, you can tell the people who are going to be buying the raw material and the inventory to produce your final product: this is what I need. Whether that's one supplier or a global sourcing network.

What I want you to take from this, and it holds at every level of maturity: gathering data isn't a spreadsheet task, or an integration project you bolt on at the end. It's a design decision you make at the beginning. The forecast, or the fancy platform — that's the easy part. The plumbing underneath it is the real work. Get that plumbing right, and forecasting stops being guesswork and starts being a decision you can stand behind.

A tool can only ever be as good as the process it sits on top of. Fix your data where it's born, not where it starts hurting you.

That's it for this one. Follow the show so the next episode finds you, and the newsletter goes out every Tuesday — link below. See you next time on The Forward Deployed Operator.