TL;DR

Someone asks the simplest question in the room. How much do we spend with this supplier? Three people open three systems, and three different numbers come back. None of them is wrong, exactly. The meeting stops anyway, and somebody volunteers to “go reconcile it offline,” which everyone understands to mean the question will not get answered this quarter.

We have watched that exact silence in a manufacturing procurement review and in a social-services intake meeting where the noun was a client instead of a vendor. Different sectors, different systems, same stall, same cause. Nobody ever agreed on what to call things.

This is the least glamorous problem in operations and the one we keep finding underneath everything else. It is not a reporting problem. It is not a tooling problem. It is a naming problem, and it is the foundation every process, handoff, automation, and AI pilot is quietly standing on.

You have plenty of data

The complaint we hear most often, in almost identical words, is some version of: we have dashboards everywhere and I still cannot tell you what we sold, or spent, or delivered.

The assumption underneath it is that something is missing. It almost never is. You have plenty of data. It is sitting in systems that were never designed to agree with each other, and no one ever made them.

Picture a single vendor, written three ways. One spelling in the ERP. Another on the purchase order. A third in a spreadsheet a regional team keeps by hand because the official system was too slow the week they needed it.

One entity. Several names. Zero reliability.

Now your spend analysis splits one supplier into three, and the volume leverage you thought you were bringing to the negotiation was never real. You walk in believing you are a mid-size account. You are, in the vendor’s system, three small ones.

This is the disambiguation problem, which is a formal-sounding phrase for a very dumb and very expensive situation: one thing, written several ways, and now nobody, human or machine, can tell they are the same.

It is not a data volume problem. It is a data agreement problem. That distinction is the whole issue, because the two have completely different fixes and almost everyone buys the wrong one.

Why nobody fixes it

Because naming sounds like admin.

That is the honest reason. It has no launch date, no demo, and no slide. It is the task you hand to whoever is newest, the thing nobody wants to own, and it never survives contact with a quarter that has real priorities in it.

But it is the one thing that, when it is wrong, quietly breaks everything sitting on top of it. You can build the most beautiful process in the world. If the foundation is wobbly, the whole thing tilts.

So instead we reach for a tool. And this is the part worth sitting with, because the reflex is identical at every size. A founder buys an app. A mid-market team stands up a module inside the ERP. A large enterprise commissions a six-figure platform and staffs a program around it.

Different budgets. Same move. Every one of them buys something to sit on top of the mess rather than going down to where the mess starts.

I do not start with a tool. I start with a shovel. You follow the data back to where it is actually born, before you automate or integrate a single thing. Because if you skip that, the tool does exactly what you built it to do: it takes your ambiguous, contradictory names and processes them faster. Nothing is fixed. You have bought a very expensive way to be wrong at scale.

The framework: One Name, Everywhere

Here is the rule I will defend. Every product, every component, every vendor gets one identifier, one definition, one owner. One name it is known by, everywhere it appears.

Three tests. An entity passes or it does not.

1. One identifier. There is a single key for this thing, and it is the key every system actually joins on. Not a name, not a description, a key. The test is mechanical: pick a vendor and try to trace it across three systems using only the identifier. If you need a human to say “oh, that one is also us,” the identifier is decorative and your integrations are running on hope.

Watch for the classic failure, which is having an identifier that nobody uses. Most organizations we go into already have a vendor number. It exists, it is just not what people search by, type into the PO, or label the folder with. An identifier that is not the thing people reach for is not an identifier. It is a field.

2. One definition. Everyone means the same thing by the word. This is the test that gets skipped, and it is the one that causes the arguments in the room.

“Active vendor” means something different to procurement than to finance. “Delivered” means the truck left in one system and the customer signed in another. “Unit” means an each, a case, or a pallet, depending on who typed it. When two teams report different numbers and both insist they are right, they usually are. They are answering different questions that share a word.

So write the definition down, in one sentence, in language a new hire can apply without asking. If you cannot write it in a sentence, you have found a real disagreement that was hiding inside a shared vocabulary, and finding it is the work.

3. One owner. A named role decides when this changes.

Not a team, not a committee, not “data governance.” A role, so it survives the person leaving. This is the test that keeps the other two alive, because identifiers drift and definitions get quietly reinterpreted, and without an owner the cleanup you just did has a shelf life of about two quarters.

The owner does not have to be senior. They have to be findable, and they have to be the one who says yes or no when someone wants to add a spelling.

What this looks like when it holds

The gains are not the ones people expect. They are not “cleaner reports,” though you get those.

What actually changes is that questions become answerable in the meeting instead of offline. Reorders trigger against one thing instead of three half-quantities. Invoices match purchase orders, so nobody is reconciling by hand on a Thursday. A new person can be handed the work and find it, because “oh, those two names are the same product” stops being knowledge that lives in one head.

And the automation stops breaking. Every brittle integration we have been called in to rescue was brittle for the same reason. It was not a bad build. It was a good build sitting on names nobody had agreed on.

Why this matters more now

AI does not fix any of this. It inherits it.

A model cannot look at three spellings and decide they are obviously the same vendor. It has none of your intuition and none of your institutional memory. It takes what you gave it, literally, and it acts at machine speed.

So a garbage taxonomy no longer gives you garbage slowly. It gives you confident garbage, instantly, at scale, in a tone that sounds completely certain. You do not get a smart answer. You get a confident wrong answer, faster.

That is more dangerous than a person getting it wrong, because at least the person hesitates. The hesitation was doing more work in your organization than anyone gave it credit for.

This is also why clean data beats company size for AI readiness, and why the readiness conversation is so often held at the wrong altitude. A ten-person operation whose entities pass all three tests is more ready than a five-hundred-person one whose vendor master has been accumulating spellings for a decade. Readiness is not something you unlock at a headcount or a budget line. It is something you either did or did not do to your foundations.

SAVE THIS

One identifier. One definition. One owner. One name it is known by, everywhere it appears.

Get the names right and everything downstream gets easier. Get them wrong and you will spend the next two years wondering why nothing quite works.

Monday morning

Four things, none of which require a budget.

1. Run the three-answer test. Pick your largest supplier. Ask three systems what you spend with them. Write down the three numbers. That gap is your business case, and it is more persuasive than any slide you could build.

2. Take twenty and twenty. Your top twenty vendors by spend and your top twenty products or services by volume. Not the whole master. Forty entities is a week of work and it covers most of your risk.

3. For each one, answer the three questions in writing. What is the identifier, and is it the one people actually use? What is the definition, in one sentence? Who is the role that owns changes? Blank answers are the finding. Do not fill them in optimistically.

4. Name the owners before you clean anything. Cleaning without ownership is a project that reruns every year. Ownership without cleaning at least stops the drift while you work.

If you are about to start an AI pilot, do this first. It is two weeks, and it is the difference between a pilot that produces something you can trust and one that produces something that sounds right.

Naming is not admin, and it was never for the machine’s benefit. It is what lets the work leave your hands, so the new person can pick it up, the system can run without you in the room, and you can walk away without the whole thing tilting.

Naming is an exit strategy.

Share this with the person who owns your ERP, your master data, or your next AI pilot. Especially the one who has been told the naming cleanup can wait until after the platform goes live.

This is the work I train, on real operations, not case studies. FDO School is an 8-week live cohort where you go inside an actual company, fix a real problem, ship a working AI system, and leave with the build, the case study, and the title: Forward Deployed Operator.

Join the waitlist

OPS INTEL

Five on my radar this week, all versions of the same lesson: the foundation decides what you can build.

Only 6% of businesses say their data is ready to scale AI 👀 Dun & Bradstreet’s AI Momentum Survey covers 10,000 businesses across 32 countries. More than three-quarters now report measurable ROI from AI. Six percent say their data is fully ready to support it at scale. That gap is not a technology gap and no platform closes it. It is the naming, the definitions, and the ownership nobody wanted to do. (⚠ verify release date — search results show both July and early August 2026.)

AI agent sprawl is now a board-level governance problem ↑ Roughly 31% of enterprises are running at least one agent in production, only about 21% have a mature governance model for them, and 52% name data quality as the biggest blocker to deployment. Read that last number next to the first: half the organizations deploying agents already know the foundation is the problem and are deploying anyway. The window to design governance in, rather than retrofit it after the first serious failure, is the window you are in right now.

Gartner: organizations will abandon 60% of AI projects that lack AI-ready data ⚠ The prediction runs through 2026, so we are inside the year it was written about. The supporting finding is the one worth sitting with: most surveyed data-management leaders did not know whether their practices were adequate for AI. Not “knew they were behind.” Did not know. You cannot answer that question without first being able to say what your entities are called.

EU AI Act regulatory sandboxes were due from member states in August 2026 👀 The obligation is to demonstrate, under supervised testing, that a system operates within legal boundaries. Operationally that means tracing a decision back to the records it acted on. If the same entity exists under three identifiers, you cannot produce that trace on demand, and the compliance answer and the operations answer turn out to be the same answer.

SAP ECC support ends December 2027, and most customers have not moved ↑ Mainstream maintenance for ECC 6.0 ends December 31, 2027, and by most counts only about a third of the original customer base has migrated. Every one of those remaining migrations is a master data project wearing a technology project’s clothes. Unvalidated or duplicate records do not get cleaned by the move. They arrive on the other side with a bigger audience. Naming is the cheapest phase of any migration and reliably the first one cut.

If there is a question in your business that takes three systems and a reconciliation to answer, reply to this email. I read every one.

This week’s episode: “Clean data beats company size for AI readiness.” Watch or listen here:

Listen to the podcast