In a recent article, The Information Difference’s Andy Hayler discussed Tips for master data management best practices.

MDM Technology is not all the same

Andy observed that many companies naively believe that all MDM technology is the same and that therefore it is adequate to go with any vendor. Alternatively, companies may entrust their choice to consultants who themselves have very little or no experience in this space.

In many cases, he says, these consultants make “baffling” recommendations, shortlisting suppliers with no track record or fragile solutions. In most cases. the more obvious, best-fit solutions do not even make the shortlist, leaving companies no sensible options.

So what should you consider when selecting an MDM vendor, or choosing a consultant to support you?

MDM must be business-lead

Andy is correct when he points out that MDM must be business-led.

If a consultant is brought in merely to justify a predetermined technology solution, then the chances are that you will end up with a poor shortlist. For example, we were approached to subcontract on a project where the client sought an MDM strategy and business case. However, the actual proposal was to justify the selection of a pre-existing stack vendor – where no real business requirement or specification had been defined.

If, however, business data owners are involved prior to making a technology decision then it is more likely that any resulting technology selection will address the needs of this community, rather than merely providing a set of tick boxes for IT Architecture.

Data governance, the art of business-driven data management is a critical success factor for MDM.

Choose Multi-Domain MDM Solutions

Andy’s second recommendation is that companies select multi-domain solutions. We recommend the same, although we suggest a process-oriented approach as this enables focus and prioritisation on the data necessary to support specific, key business processes.

Historically, MDM solutions focussed on a single domain, such as Customer, Employee or Product.

For many vendors, their MDM approach has been to acquire many vendors, with differing capabilities and architectures, and propose one, or more, of these solutions to address different domains. Most vendors now claim to be multi-domain but, as Andy points out, “the reality rarely matches the Powerpoint.”

More modern MDM solutions, like Precisely Enterworks, are designed from the ground up to be multi-domain and, more recently, to be process driven.

Most of these solutions leverage best-of-breed third-party data integration or data quality capability as integrated components, allowing companies to leverage existing technology investments or plug existing gaps, such as enterprise data quality, without making wholesale changes to existing platforms.

Open Integration Architecture

As importantly, best-of-breed solutions tend towards an open integration approach designed to facilitate data sharing between the MDM platform and the enterprise architecture. This contrasts sharply with the approach taken by many stack solutions that attempt to lock clients in by making data integration difficult. Very few environments have all their data sitting within a single vendor environment, meaning that some data sharing is always required.

Shift away from monolithic ERP solutions

For example, in one environment with a large ERP investment, the most critical data domains are sitting outside of the ERP. Any MDM solution must be able to plug into the ERP, but must also be able to push and pull data to these other critical sources.

In this instance, the consulting recommended approach of sticking with the ERP vendor for MDM may in fact create significantly higher risks and costs than a third-party solution, particularly given that MDM is not a core focus for the ERP vendor.

Considering Graph Technology

Since this post was written in 2013, a new master data management paradigm is emerging. Graph technology enables organisations to work with data in more flexible ways, in particular where there is a need to understand and uncover hidden relationships between parties. While multidomain MDM platforms are still a good choice for traditional MDM problems, 4th-generation MDM solutions should be considered for problems like fraud management or to understand buying relationships and influence.

Think big, start small

I also support Andy’s last point – “think big, start small.”  Thinking big, particularly when it comes to business requirements definition and planning the roadmap is critical to ensuring that you do not quickly outgrow your chosen technologies. And yet, the implementation should be broken down into small, clearly defined deliverables that can ensure business returns quickly. The process-oriented approach can lend itself to this, by delivering governance and quality data to support a small set of key processes.

Data should be central

One last observation from my experience: “Don’t forget the data.”

If MDM simply becomes a process for consolidating and distributing poor-quality data then you will not achieve your anticipated results.

Data quality should not be an afterthought but should rather be defined as part of your initial business requirements. A clear understanding of your data quality requirements will help to ensure that the data quality capability selected is appropriate to your needs.

For example, at one client the MDM solution generates in excess of 30 000 potential match exceptions on master data monthly, placing an unsustainable load on the master data stewards who cannot resolve these issues quickly enough. Reducing this effort through the use of a trusted matching capability is one way to ensure a better fit to purpose.

The lessons for MDM projects are simple:

Start with business-driven data governance; understand what your data quality requirements are; select appropriate technology using consultants that have a track record in MDM delivery; and take a gradual, stepwise approach to implementation that will ultimately support all data domains and multiple business processes.