A particular scenario has played out all too often in the past decade. A CEO develops a new vision for his enterprise and announces that becoming information-centric and customer-centric are at the heart of his vision. The executives, directors and managers tasked with delivering the new reality try to understand the vision and how to implement it. Sooner or later, they've heard from IT and data management about data quality, data governance and master data management as an assured path to a data-centric world and customer-centricity. The executives sign up for all these things and go back to the CEO for resources, telling him the path to his vision has been found.
As usual, the CEO asks for the business case and an explanation of return on investment. ROI is articulated using the IT industry logic that highlights positive effects of simplifying and centralizing integration, with data quality and data consistency improvements as the driving benefits. However, these benefits do not match the CEO's goals, which remain far from being achieved. The CEO wanted to understand, reorganize and manage all the touchpoints in the customer lifecycle. He wanted the enterprise to become truly customer-centric, rather than account-centric and merely focused on individual, isolated transactions with the customer. Instead, the CEO is left with an enterprise that has better control and quality of master data, but the operational and analytical processes and lifecycles remain nearly the same. Sadly, there is a widespread IT view that operational and data quality efficiencies are the totality of MDM. The CEO might want to transform the enterprise, but IT is typically unable to achieve this because it is incapable of finding and mitigating the root causes of inconsistency and brittleness.
IT and data management professionals often talk about the principles of understanding "the what" before "the how" and fixing data problems upstream rather than downstream. Yet, as IT and data managers, we rarely follow our own principles when it comes to the true need for MDM. On the one hand, the high-level requirements are not fully understood, and a study of data management trends is assumed to be the answer. On the other hand, a lot of master data issues are the result of poorly defined lifecycles. More often than not, instead of fixing the source (i.e., the lifecycles) we opt for creating all sorts of unification rules and additional controls downstream.
On many occasions, we have come across corporations and industry speakers talking about MDM challenges and the importance of finding the driving strategic business value. But, really, what is the part of the business strategy that will directly benefit from a proper MDM program, and how do you hook yourself to it? Consider some nontransformative answers first:
- It's not isolated data quality benefits and their impact;
- It's not centralized data stores with sophisticated history preservation mechanisms;
- It's not operational efficiencies from master data consistency;
- It's not isolated KPIs that could represent tactical improvements of specific business capabilities;
- It's not simplified analytics.
All these points bring improvements to an enterprise but will not fundamentally change it, because they are not solving the root causes of business problems. They are not looking into the business concepts, what they represent and how processes interact or use such concepts. All these benefits sidestep the actual meaning and merely focus on the representations stored in technology. What we must understand is how business processes use and manage master concepts, not how they manage the data that represents them.
For instance, it is quite a different thing to standardize the capture of customer name across several transaction lifecycle interactions than it is to standardize customer engagement in a new lifecycle decoupled from the transaction lifecycle interactions.
We are looking for fundamental business transformation that will take the business into new ways of perceiving, understanding and developing customers, employees, suppliers, assets and securities. We are looking for business transformation that moves in line with the business goals. And though executives understand that data is at the heart of proper and well-executed business transformation, experience tells us that more often than not, the business transformation is limited to improved data quality side effects that fail to realize the true value of an MDM program.
Where do we begin in order to find strategic business value? The first step is to understand a company's operational environment from a master data viewpoint. The importance of master data is not just the values we carefully control and manage, nor the quality and consistency of them, but the real-life concepts and statuses they are supposed to comprehensively represent. This, until very recently, has been completely overlooked. In fact, our last 50 years of data technology has resulted in the entombment of semantics under complex, abstract data models that captured idealized constituents of the concepts being represented. The true business master data semantics consists of understanding each one of the key business actors and key business concepts independently, continuously and comprehensively.
It is doubtful that MDM has ever actually managed to change and reconfigure the lifecycle of master concepts created and controlled within the enterprise, let alone external concepts and actors (e.g., suppliers). In fact, when an MDM program deals with external concepts or actors, it commonly captures small portions of their states that are then tracked in isolation through specific, internal company processes or lifecycles. Hence, MDM typically influences a corporation to be tidier with how they store siloed point views of master concepts and actors. This is something Len Seligman of MITRE calls "silos of excellence."
We must go back to basics. What do these master data concepts mean, and how do we see and influence their lifecycles, especially when they are external? From a business point of view, we have internal lifecycles that are touched and managed by operational processes. When external actors are involved, we typically move to an enterprise or product-centric lifecycle and capture interaction details. Here we lose the opportunity to change the business and revert to a limited improvement in data quality or other more tactical benefit. But this is where the business must restructure to reach out further and keep up to date with understanding the lifecycles of customers, suppliers and employees. By doing so, they are able to make their operational processes work by understanding the world from the points of view of their customers, suppliers, employees and other master concepts.