Last week, we discussed whether MDM should be treated as a project or a program. The main point was that this choice affects far more than planning language. It shapes funding, ownership, expectations, and the level of patience the business brings to the work. When MDM is treated like a short-term project, teams tend to focus on delivery milestones and visible outputs. When it is treated like a program, the focus shifts toward durability, stewardship, and the ongoing decisions required to keep shared data useful over time.

That discussion matters here because the next mistake often appears before governance breaks down and before quality issues become visible. It shows up in the order teams choose for design.

This week, the question is whether master data should drive business process, or whether business process should drive master data. In practice, this is one of the most important sequencing decisions in any large program that touches shared data. It rarely gets framed so directly, but it shows up in the way teams conduct workshops, define entities, prioritize requirements, and decide what must be standardized first.

My view is clear. Business process should almost always drive master data. Master data is supposed to reflect how the organization works, not dictate it from a whiteboard before the work itself is understood. When teams reverse that order, they often create a model that looks disciplined at the start and becomes unstable as soon as real systems, real decisions, and real exceptions begin pressing against it.

Master Data vs Business Process: What Comes First?

Why This Question Matters More Than You Think

A familiar pattern plays out in many environments. A team realizes customer data is inconsistent, reporting is unreliable, or integration work is getting harder than it should be. The response sounds sensible. Standardize the data model. Define the core entities. Create a shared structure that other systems can use. At first, that approach feels efficient because it appears to address the visible mess directly. You gather stakeholders, define terms like Customer, Product, and Account, and move toward a clean enterprise view. The output looks mature. The diagrams are tidy. The model feels like progress.

The trouble usually begins later, and it often begins in places that seem unrelated to the original design session. Finance asks why its active customer counts do not match what sales is showing. A support team complains that the customer hierarchy in the portal does not line up with the account relationships in the CRM. Integration developers discover that one source system treats a customer as a legal billing entity while another treats it as a sales account with territory ownership, and a third treats it as a service location tied to contracts and contacts. By then, the problem is no longer a matter of terminology. The business is already operating through different process lenses, and the model that was meant to unify those views is now absorbing contradictions it was never designed to hold.

What Happens When Data Drives Process

This is why the question matters so much. Process defines meaning before data ever captures it. The same word can carry very different responsibilities depending on where it sits in the flow of work. Sales may care about pipeline ownership, territory rollups, and parent-child relationships that support quota management. Billing may care about legal entities, tax treatment, payment terms, and invoice responsibility. Service operations may care about site-level relationships, installed products, and escalation paths. All of those may be attached to something called customer, but that does not make them the same thing. When the model is built first, teams tend to compress those differences too early. They assume one structure can absorb them and clean them up later. What they usually get instead is a record that means too many things at once and satisfies none of them cleanly.

You can see the consequences in how organizations start compensating for the model. A report gets a custom calculation to reinterpret hierarchy logic. An API adds a translation layer because the source system and target system disagree on what a customer record represents. Analysts export data to spreadsheets and patch parent-child relationships manually because they do not trust what the hub is returning. A field that was supposed to be authoritative becomes advisory. A status code that was meant to be simple acquires exceptions, hidden meanings, and workarounds that only a few people understand. At that point, the model may still exist as the official structure, but the real business logic has drifted into reports, ETL jobs, middleware, and tribal knowledge.

That drift is one of the clearest signs that data was asked to lead when it should have followed. It is tempting to describe the resulting problems as data quality issues, but that diagnosis is often too shallow. Missing values, duplicates, and mismatched hierarchies are symptoms. The deeper issue is that the model is carrying unresolved process disagreement. If the business has not aligned on what a record is supposed to support, no amount of structural polish will make the data stable.

This shows up especially clearly in mergers, system modernizations, and enterprise reporting programs. Two business units may use the same vocabulary while operating with different assumptions. One may roll customers to a legal parent for billing and contract management. Another may roll them to a sales parent for territory planning and performance measurement. Both structures may be valid because they serve different decisions. Problems begin when the program assumes one of those structures must replace the other simply because an enterprise model requires one definition. That is the point where master data stops reflecting business reality and starts trying to control it. The friction that follows is not surprising. It is built into the sequence.

Why Business Process Must Come First

There is also a timing problem that process-first thinking exposes much earlier than model-first design does. Data is not just static structure. It moves through events, approvals, handoffs, and state changes. An order at creation time is not the same thing as an order ready for billing. A customer prospect is not the same as a contracted account. A product in design is not the same as a product available for fulfillment. Those transitions matter because they shape what data must exist, what relationships must hold, and what systems are allowed to act next. When teams jump straight to fields and keys without first understanding those process transitions, the resulting model often looks complete but behaves poorly. Required fields appear at the wrong point in the workflow. Statuses become overloaded. Downstream systems receive records that are technically valid and operationally premature. These are the kinds of issues that slip through design reviews and surface later in operations, usually after integration teams are already under pressure.

Risk follows the same pattern. Not all data defects matter equally, and process is what tells you the difference. A duplicate supplier in a low-use reference list may be irritating. A duplicate supplier that affects payments, tax reporting, or vendor onboarding has a very different consequence profile. A missing region code in an internal report may be annoying. A missing legal entity attribute that blocks invoice generation or causes contract errors is something else entirely. Without a process view, programs tend to prioritize based on what looks messy rather than what actually threatens business execution.

That is why I keep coming back to the same principle. Master data is not the business. It is a managed representation of the business. It should be shaped by how work gets done, how decisions are made, and how shared entities move across systems and teams. If that order is respected, the model has a chance to become durable. If that order is reversed, the model may still look sophisticated, but it will spend its life absorbing exceptions and being reinterpreted by downstream logic.

When Master Data Can Influence Process

There are, of course, cases where data influences process. Regulatory requirements do this. Platform constraints do this. A packaged ERP may require a certain structure, a certain level of normalization, or a certain way of handling identifiers and hierarchies. Governance can also exert pressure by standardizing naming, stewardship rules, and acceptable definitions across domains. But even in those cases, data is constraining options, not defining the business from scratch. The process still provides the context for deciding whether those constraints are workable, where they create tension, and which trade-offs are acceptable.

A Simple Framework to Get This Right

The practical answer is not complicated, though it does require discipline. Teams need to resist the urge to standardize the data model before they understand the business motion underneath it. That does not mean avoiding modeling. It means sequencing it correctly.

If you want alignment between business and data, the sequence matters.

Follow this.

Step 1: Map the process

Start with:

• Workflows
• Decisions
• System interactions

Ask:

• What happens first?
• What changes over time?
• Where do handoffs occur?

Step 2: Identify entities

Now extract:

• Core objects
• Roles they play
• Relationships between them

Do not merge roles too early.

Keep them separate until proven otherwise.

Step 3: Define attributes

Only now should you define:

• Fields
• Keys
• Constraints

At this point, your data reflects real behavior.

Step 4: Validate with real use cases

Test your model against:

• Reports
• APIs
• Operational workflows

If it does not support them cleanly, adjust.

How to Spot Misalignment Early

What is important about that sequence is not just that it produces a better model. It changes the nature of the conversation. Instead of arguing about definitions in the abstract, teams walk through actual work. Instead of assuming a shared term must mean one thing everywhere, they ask what the record needs to do in each part of the business. Instead of treating every inconsistency as a cleanup problem, they can distinguish between true defects and legitimate differences in use.

A supplier example makes this clearer. In many organizations, procurement and finance appear to be talking about the same supplier while using different identifiers, names, and grouping logic. Procurement may be concerned with sourcing relationships, approved vendor status, and operational buying channels. Finance may care about the legal entity, tax identity, remit-to details, and payment risk. If you begin with the model, the instinct is to merge the records and eliminate the inconsistency. If you begin with the process, you often discover that the apparent inconsistency reflects different business responsibilities that need to coexist. The correct answer may still involve consolidation, but it will be informed consolidation rather than premature flattening.

The same dynamic plays out with customer hierarchies, product structures, employee relationships, and asset records. One hierarchy supports quota planning. Another supports invoicing. Another supports service routing. One product structure supports engineering traceability. Another supports ordering. Another supports analytics. When teams start with process, they can decide whether those views belong in the hub, should remain separate, or need controlled mappings between them. When they start with data, they tend to force a single answer too early and spend the next year building exceptions around it.

Final Thought

Over time, process-first design produces something more useful than a clean model. It produces a model that can survive contact with the business. It may not look as elegant at the start. In fact, it often feels slower because more questions are asked earlier. But those questions are the real work. They surface what the entity means, where it changes, who owns it, and which relationships matter enough to govern. That kind of clarity is much harder to bolt on later.

So when the question comes up, directly or indirectly, my answer is the same. Master data should almost never drive business process. Business process should drive master data. The process tells you what the business is doing, what a record must support, where meaning changes, and where risk becomes real. Master data should capture that reality as faithfully as possible. Once it starts trying to define the reality before the work is understood, the model may still look strong for a while, but the business will keep finding ways around it.