Choosing an MDM application? Don’t just buy the brand

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

Andy observes that many companies naively believe that all MDM technology is the same and that therefore itis 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 extremely weak solutions. In most cases. the more obvious, best fit solutions do not even make the short list, leaving companies no sensible options. So what shoulod you consider when selecting an MDM vendor, or choosing a consultant to support  you.

Andy is correct when he points out that MDM must be business lead. 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 was looking for an MDM strategy and business case. However, the actual proposal was to justify the selection of a pre-existing stack vendor.

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.

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 are designed form 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 to plug existing gaps, such as enterprise data quality, without making wholesale changes to existing platforms.

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 level of data sharing is always required.

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.

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, 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.

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 business 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.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.