Digital Future & Strategy

Enterprise MDM governance often looks strongest on the day it is designed. The governance council has been named. Data Owners and Data Stewards appear in the organization chart. RACI matrices have been approved. Workflow roles exist in the MDM platform. Then the system goes live. A country organization requests an exception to a global customer standard. Two business units disagree about whether two supplier records represent the same legal entity. A product attribute fails repeatedly, but nobody wants to change the upstream process that creates the error. A Data Steward can identify the problem but cannot compel the business function to resolve it. At this point, the real governance model becomes visible. MDM governance is not proven by the existence of governance roles. It is proven by what happens when people disagree about data. That is why I would not begin a governance review by asking whether an organization has Data Owners, Data Stewards and governance coun...

The first warning sign in a troubled MDM program is rarely a red project dashboard. More often, it sounds harmless. “We have already selected the platform, so we can define governance later.” “While we are doing customer, why not add supplier and product as well?” “The business can review the design once IT finishes the first version.” “We will establish the operating model after go-live.” None of those statements proves that an MDM initiative will fail. But when several appear together, they can indicate something more important: the program is beginning to drift away from the business problem it was supposed to solve. I find that more useful than asking whether an MDM project is simply “successful” or “failing.” By the time failure is obvious, much of the budget, architecture and organizational credibility may already be committed. The useful question is not “Will this MDM project fail?” It is “What would tell us early that the program is moving in the wrong dire...

“I understand why master data matters. But why should we fund this now?” That is one of the hardest questions an MDM team can receive from an executive sponsor. It is also a reasonable question. The project team may be looking at duplicate customers, inconsistent supplier records, conflicting product hierarchies and hundreds of manual corrections. Leadership is looking at competing investments. An ERP transformation may need funding. AI programs are competing for budget. Cybersecurity, cloud modernization and regulatory initiatives may already be mandatory. Against that background, saying that MDM will create a “single source of truth” is usually not enough. An executive business case for MDM should not begin with the value of master data. It should begin with a business problem that leadership already cares about. This changes the conversation. Instead of asking executives to invest in cleaner data, the MDM team can show how unreliable master data contributes to a...

A digital transformation can look successful from the application layer while remaining fragile underneath. The new ERP is live. The CRM has been modernized. A new commerce platform is connected. Dashboards have moved to the cloud. AI pilots are beginning to appear across the organization. Yet the same questions keep returning. Which customer is this? Are these two suppliers actually the same company? Which product hierarchy should the analytics platform use? Why does one material have different attributes across plants? Which system contains the authoritative address? These questions are easy to classify as “data-quality issues.” But in a transformation program, they are more consequential than that. Digital transformation changes applications, processes and decision-making. Master data determines whether those changes refer to the same customers, suppliers, products, materials and locations. This does not mean that poor master data is the cause of eve...