Every cross-unit ambition an enterprise has — a unified customer view, coordinated selling, trustworthy reporting, anything with “AI” attached — rests on one agreement that usually does not exist: agreement on who the customer actually is. That agreement is the real first deliverable, and almost no one funds it first.

Ask a large, multi-division enterprise a deceptively simple question — how many customers do you have? — and watch the answer fall apart. The same account turns up again and again across different systems, under different spellings, abbreviations, and identifiers, each treated as its own separate “customer.” The organization does not have a customer list; it has a dozen overlapping, contradictory ones, none of which agrees with the others, and no reliable way to tell that three of them are the same company.

This is the condition underneath most stalled cross-unit transformations, and it is why the single most important deliverable in such a program is almost never the one on the roadmap. Before the unified dashboard, before the cross-sell engine, before the coordinated account planning, there has to be a shared data contract: an agreement, enforced, about how the enterprise identifies and describes its customers. It is Epic Zero — the enabler that everything else inherits from — and treating it as a technical chore to be handled later is the mistake that quietly dooms the visible work above it.

The symptom: many truths, no source of truth

The visible problem is fragmentation. An enterprise that has grown through acquisition and reorganization ends up with many separate customer-facing systems that do not talk to each other. The same customer exists independently in each, under a different name and a different identifier, and nothing reconciles them.

The costs compound quietly. Sellers spend a large share of their time gathering and reconciling customer data rather than selling, because there is no single place that tells them the truth. Divisions approach the same account without knowing another part of the business already owns the relationship. Cross-sell opportunities — often among the largest untapped value in the whole portfolio — go unrealized because no system can even see that the same customer buys from three different units. And every downstream ambition that depends on knowing the customer inherits the corruption: reporting is untrustworthy, incentive calculations misattribute, and any AI layered on top produces confident output from incoherent inputs.

None of this is a technology failure in the usual sense. Every one of those systems works. What is missing is the agreement that would let them mean the same thing by “customer.”

What a shared data contract actually is

A shared data contract is not a database, and this is the distinction that matters most. It is an agreement about identity and meaning, which a database then enforces. In practice it has a few core parts.

It has a universal customer identifier — one durable ID that follows a customer across every system, so that the same company is recognizably the same company everywhere. It has a master record that serves as the single source of truth for customer identity, sitting above the divisional systems rather than inside any one of them. It has enforced naming standards, so that one account cannot quietly become a dozen variants. It has a defined model of roles and relationships — the recognition that the parent organization, an individual site, an operating unit, and the billing entity are different roles, not competing records for “the customer.” And it has survivorship rules: when two records conflict, an explicit, agreed logic for which value wins and becomes the definitive record.

The reason to call it a contract rather than a schema is that its value is entirely in the agreement. A data model that the divisions have not agreed to is just another system to reconcile. The contract is the thing downstream systems can rely on — and reliability, not storage, is the point.

Why it is Epic Zero

In a scaled program, the big, visible epics — the unified customer view, the cross-sell coordination, the account-planning platform — all depend on the shared data contract, and none of them scales without it. That dependency is exactly what makes the contract dangerous to plan, because it has no business stakeholder who will ask for it by name. No sales leader requests “master data management.” They request the dashboard. The data contract is the enabler beneath the dashboard, and enablers, as the traceability piece in this series argued, have to inherit their value from the business features they unlock, or they get deprioritized to death.

So the shared data contract has to be recognized and funded as the foundation it is — Epic Zero, the thing that comes before the numbered epics because they all rest on it. The organizations that get this wrong build the visible epics on the fragmented foundation, produce something that demos beautifully on curated data, and then discover it cannot scale past the pilot because the underlying identities never agreed. The organizations that get it right fund the unglamorous foundation first and let the visible work stand on something solid.

The method that actually works

Building a shared data contract has a reputation for being a multi-year boil-the-ocean exercise, and done naively it is. A few principles keep it tractable.

Clean data first — do not migrate bad data. The instinct to lift everything into a new system carries the fragmentation along with it. The discipline is to enforce the standards at the point of entry and bring data across only once it conforms. You are not copying the mess; you are establishing the clean layer and admitting data to it on the contract’s terms.

Coordination, not control. The contract does not require ripping out the divisional systems or seizing their ownership. It can sit as a thin unifying layer above them, providing shared identity and visibility while the units keep operating. Framing it as coordination rather than control is not just diplomacy; it is what makes the units willing to participate, because it does not threaten their autonomy.

Start with a pilot, then expand. Rather than reconciling every customer at once, start with one segment or one set of strategic accounts, prove the cleanup and the contract on it, and expand systematically. A pilot turns an impossible-sounding program into a sequence of finishable steps.

Use the specification to surface disagreement early. A data-contract spec’s first job is not to be perfectly right; it is to make the cross-unit disagreements visible so they can be resolved. Getting a draft in front of the divisions early — precisely so they argue about what a customer is — is more useful than polishing a definition in private that no one has agreed to.

The governance that keeps it alive

A shared data contract decays the instant it stops being enforced, so it comes with governance or it does not last. That governance is mundane and essential: a change-control workflow so that important accounts cannot be created or altered without review; the ability to lock high-value records against unmanaged edits; approval routing so the right owner signs off on changes that affect the enterprise; and, underneath all of it, a named business-side stewardship function that owns the definitions and resolves conflicts. The platform supplies the enforcement mechanism; the business owns the meaning. Without that stewardship, the contract erodes back into fragmentation one well-intentioned local workaround at a time.

The hard part is the agreement, not the technology

It is worth being blunt about where the difficulty actually lives, because it is not where teams expect. The technology to store a definitive record and enforce a naming rule is well understood and not the obstacle. The obstacle is agreement. Getting several divisions to agree on what a customer is — the parent company, the site, the operating unit, or the entity that actually signs the contract — is a negotiation, not a data-modelling exercise. Agreeing who is allowed to create or change an important account touches real authority. Agreeing the naming standard means someone’s familiar convention loses.

This is why the shared data contract is genuinely a contract and genuinely hard: it asks autonomous units to give up local control of how they describe the world, in exchange for a shared truth none of them owns alone. The technical artifact is the easy downstream expression of that agreement. The agreement is the work.

The real point

Master data management gets filed under IT, scheduled late, and starved, because it looks like plumbing. It is not plumbing. It is the treaty that makes every cross-unit ambition possible — the single agreement about identity that the unified view, the cross-sell engine, the trustworthy report, and the credible AI all silently depend on. Get it first and the visible epics have somewhere solid to stand. Skip it, and everything you build above it will demo well and fail to scale, for a reason no one will quite be able to name.

Call it what it is: Epic Zero. Fund it first, govern it forever, and treat the agreement — not the database — as the deliverable.