Ask an operations team whether they have a data problem and they will usually say yes — too much of it, in too many places, moving too slowly.
Then watch a real dispute.
The site says the item is in stock. The warehouse says it is allocated. The ERP says it is a different SKU. The customer is ordering with their own part number. Commerce thinks the pack is each. The contract is written in cases. Two customer records exist, one in CRM with credit, one on the storefront without it. "Shipped" in the platform is not "shipped" in finance.
That is not a volume problem. The company is not drowning in facts. It is drowning in competing definitions of the same fact.
How information moves is a different article. Pipes can be fast and still carry a lie. This one is about meaning: identity, ownership, and which system is allowed to win.
The Same Object, Several Lives
Commerce data looks complex because each application was allowed to invent its own version of the business.
A product accumulates identifiers: internal SKU, manufacturer number, customer number, barcode, marketplace ID. If those are not bound to one canonical item, every channel searches a different catalog. Product content as operating infrastructure is what happens when that identity never becomes a governed record. Search, pricing, and inventory then argue in public.
A customer splits the same way. CRM has the account. Commerce has a shopper. ERP has a bill-to. Loyalty has a card. Service sees whoever called last. Personalization and credit both fail, for opposite reasons: one cannot recognize the buyer, the other recognizes the wrong one.
Inventory splits into physical, sellable, allocated, in-transit, and promised. Teams use the word "stock" as if those were synonyms. They are not. A POS sale against physical units and a website sale against ATP are different events. If the names are shared and the meanings are not, oversell is a translation error.
Price splits into list, contract, promotional, and what a rep quoted last week. Order status splits into whatever each system needed for its own workflow. "Complete" for fulfillment can still be "open" for invoicing.
None of this is exotic. It is what happens when systems of record were never named, so every system became a record.
Someone Has to Be Authoritative
The useful executive decision is not "we need a data lake." It is: for this object, which system is allowed to be right, who may change it, and what happens when another system disagrees.
Product identity often belongs in PIM or ERP, not in the storefront CMS. Account identity often belongs in CRM or ERP, with commerce consuming it. Inventory position belongs in the warehouse or ERP, with channels publishing a derived ATP, not a second count. Financial status belongs in ERP. Quote authority belongs in the commercial rules, not in a spreadsheet beside them.
Those choices are political before they are technical. A team that can edit the product in three places will, and the catalog will drift. A team that can create a customer in commerce because CRM "takes too long" will, and credit will not follow the order.
Master data is the name for the boring layer that makes those choices stick: one product, one account, one location, one unit conversion table. It is not a warehouse of every click. It is the small set of objects the company refuses to let fragment.
Governance is the unfashionable word for this. It is not a policy PDF. It is validation at entry, an owner for each domain, a rule for duplicates, and an exception path when two sources conflict. Without that, synchronization just copies the argument faster.
Taxonomy is a meaning decision too. If "filter" is a category in one channel, a spec in another, and a SKU type in the ERP, search and reporting will never reconcile. Agreeing the tree is slower than adding a field. It is cheaper than years of mapping.
Events need definitions too. "Order created" has to mean the same commercial fact in commerce, OMS, and ERP, or downstream automation will fire on the wrong moment. Replatforming the storefront does not settle those definitions. Launching without them guarantees a phase-two reconciliation project.
Connect After You Can Name the Thing
Companies often buy integration to escape meaning work. Connect everything, and the truth will emerge.
It does not. If case and each are both called "unit," the integration will sell the wrong quantity at high speed. If two customer IDs are both "the customer," loyalty and invoices will attach to different people. If list price and contract price share a field, the site will show a number the account will not pay.
Normalization is the unglamorous work of saying: this identifier is primary, this one is a cross-reference, this unit converts, this status maps, this record is a duplicate. Semantic consistency is agreeing that "available" never means "on a truck we have not received."
List price versus customer price is the version finance notices first. If both are stored as "price," every channel will pick the convenient one. The field names have to encode the rule, not the hope that users will remember which is which.
AI makes the cost of skipping this sharper, not different. A model will not referee two product numbers. It will pick one and sound sure. Arizon Digital's Agentic Commerce Readiness Index includes the data backbone because agents, like employees, need a version of the business they are allowed to trust. The index does not create a system of record. Naming one does.
The Meeting Is the Symptom
When two systems disagree, the current process is often a meeting. That meeting is the master-data strategy, expressed as calendar time.
A better test: can someone point to the system of record for product, customer, inventory, price, and order status, and can the other systems be wrong without creating a second truth? If the answer depends on who is asking, the company does not have a complexity problem it can store its way out of. It has not decided what the business is.
A practical sequence is small. Pick one object that already causes fights — usually product or customer. Write the identifiers, the system of record, the allowed copies, and the person who adjudicates duplicates. Run that rule for a month. Then the next object. Do not start with a program to "govern all data." Start with the definition that is already costing orders.
Volume will keep growing. Meaning will not appear as a side effect of more pipelines. Decide identity and authority first. Then moving data is useful.