Click to learn more about author Bill O’Kane.
As the Master Data Management (MDM) solutions market continues to mature, it’s become increasingly clear that the program management aspects of the discipline are at least as important, if not more so, than the technology solution being implemented. After spending eight years as a Gartner analyst covering MDM and almost two years advising clients and prospects at a leading MDM software vendor, I have learned that three critical success factors continue to manifest themselves. While there are certainly additional items to consider, these are the ones that enterprises most often “trip over” in taking on the task of implementing MDM.
1. Start with the Right Objectives – and a Roadmap to Get You There
The biggest danger to a nascent MDM program is starting with the wrong objectives, even though those objectives can often sound quite right. The best practice here is to start with discrete and measurable business outcomes. A key acid test in this scenario is the ability to describe the outcomes of MDM in nontechnical terms that the business can understand and champion, both before and after they are delivered. If you can’t do this, then you likely have the wrong objective! A technique I’ve often used with organizations aspiring to implement MDM is to ask them to state their objectives without using the word “data.” My experience has shown that the vast majority of enterprises stumble at this point, but it’s a great method to get IT teams to see the issue that they are eventually going to have in maintaining momentum over the life of the MDM program.
It is also helpful to consider business outcomes as divided along two axes as shown below: those that make money vs. those that save money (above and below the horizontal axis, respectively), and current but sub-optimal vs. net new business processes (to the left and right of the vertical axis, respectively). While most IT teams are capable of solving those use cases in the lower left quadrant (i.e., saving money by fixing current sub-optimal processes) on their own, true digital transformation resides in the upper right quadrant (i.e., making money with net new processes), and requires full participation from the business in identifying, describing, and quantifying these outcomes.
Our objective here is to surface the questions and issues that the business will eventually ask – when the stakeholders grow impatient waiting for what they perceive are the MDM deliverables. The key is to do this before any time, resources, and funding are spent in pursuit of managing data elements that provide no real business value.
An additional error by omission that many enterprises make during this phase is to stop at creating a business justification alone, and not pushing forward one step further to a prioritized roadmap, or sequence of events, that will deliver the agreed-upon benefits in the ROI analysis. It’s also critical to obtain ratification by all senior stakeholders in the program, as this provides accountability and a potential buffer against external events such as a change in executive leadership, or a merger or acquisition. A sensible and concrete implementation roadmap and supporting cost/benefit analysis are the best way to guide and ensure the success of your MDM program into the future.
2. Coordinate MDM and Data Governance from the Very Beginning
At this point in the history of Data Management, it’s generally acknowledged that MDM and Data Governance must be coordinated and aligned in order for either of these disciplines to be successful in an organization. However, we still get many questions along the lines of “What does that really look like on the ground?” There are certainly some guiding principles that can be applied to these scenarios, and the even better news is that they usually reduce the overall workload of both the implementation team and stakeholders.
It’s best to start by limiting the data entities and attributes in your master data model to only those that serve to deliver the business value described in the first section above. Next, limit any plans and commitments to govern data, including the designation of data stewards, to those same data elements unless and until additional elements are justified as part of incremental desired business outcomes. Lastly, during the ROI and roadmap exercises described in the previous section, identify no more than three senior executives that will best serve in the Data Governance council or board, and begin discussing this role with them as early as possible. Avoid using the word “support” when dealing with these individuals; what you really are after is their “participation.” In other words, they will actually need to show up at regular bimonthly meetings and even adjudicate conflicts as they arise. Note: If no conflicts arise when establishing Data Governance, that’s a red flag that you’re not getting full participation from all stakeholders.
It’s quite common that the senior business stakeholders for MDM are either the same as the people you need to “govern Data Governance” or they have influence over those people. Approaching this subject while discussing the business benefits involved with MDM will make them more agreeable to playing a role on the governance council or board, and will save you the trouble of getting time on their calendars (and mindshare) twice to achieve the same results.
3. Rethink Multidomain MDM in the Service of the Ever-Elusive Customer 360
After all these years, it’s still extremely common for a client or prospect to state they are implementing MDM because they “need a 360-degree view” of their customers. Being charitable, this is, in fact, not a business outcome but an often ill-defined architectural concept that eventually becomes a black hole of resource, time, and funding consumption and results in ultimate failure to deliver anything.
One common issue that arises is that the concept of Customer 360 leads companies to believe that they should acquire either an MDM application that only masters customer data out of the box, or a multidomain MDM platform that the enterprise only licenses to master the customer domain. Undoubtedly, as they then begin implementation, the organization discovers that it will require the mastering of data elements from other domains (typically the product data domain at first). When this happens, they must either buy an additional MDM product or license their platform for more domains in addition to customer data. This alone is often sufficient to significantly delay the delivery of business value through MDM, and consequently Data Governance, or to stop the program in its tracks.
The answer to these scenarios lies in rethinking the concept of multidomain MDM to mean mastering – and governing – only those entities and attributes that are needed to deliver the business outcomes as described in the above section on that topic, regardless of the master data domain they happen to fall under. This, in turn, not only requires a data model-agnostic MDM platform, but also one that is not licensed by discrete master data domains (customer, material, finished product, supplier, asset, facility, etc.). This type of solution, coupled with a domain-agnostic pricing model, will provide both the flexibility needed to right-size your MDM and Data Governance programs to deliver rapid value – whether focused on customer data or not. More importantly, it provides the ability to expand your program scope and data model going forward into the future without incurring immediate significant software licensing costs.