Click to learn more about author Bruck Assefa.

Welcome back. In this article, we’ll dive into the next five myths about Master Data Management (MDM) and build off what we learned in Part I which covered the first five myths and corresponding facts. As we’ve learned, MDM can be a confusing topic, so I’d like to use Part II of this series to address additional misconceptions that organizations have which often prevent them from implementing a successful MDM strategy. In case you missed Part I of this series, click here.

Myth 6. We Don’t Need MDM Because We Have a PIM Solution

Fact: While MDM and PIM applications have overlapping functionalities, they are fundamentally designed to address different business needs. In fact, the more useful comparison is between Product MDM and PIM because MDM has a broader purview that also includes other domains including customer, vendor, asset and location. One of the key distinctions between PIM and Product MDM is that PIM deals with the management of product information, including attributes, catalogs, relationships and digital assets for the purposes of supporting sell-side use cases (e.g. supporting omni-channel commerce, generating digital catalogs or exporting validated product data in trading partner specific formats). For this reason, users of a PIM application usually are category managers, merchandisers and sales and marketing professionals.

The focus of Product MDM, however, is on making sure that product Master Data is centralized, cleansed, governed and shared to multiple business applications whether to support sell-side (e.g. eCommece), buy-side (e.g. Procurement) or in-side (e.g. BI Analytics) use cases. The emphasis often is managing a centralized definition of product data for the enterprise and enforcing Data Governance controls to ensure the product data and associated metadata are current and accurate. This means data model extensibility, Metadata Management, configurable workflow, Data Governance and Information Stewardship capabilities are important features of a Product MDM application. Therefore, Product MDM users often tend to be a combination of product domain experts, Data Governance Managers, Data Stewards and in some cases even IT professionals.

Myth 7. MDM is a Data Governance Solution

Fact: Data Governance has broader coverage than MDM. It aims to combine people, processes and technology to ensure a desirable business outcome as a result of the creation, maintenance, security, validation and use of all types of data – whether it’s Master Data or not.  This means it’s not correct to think of MDM as a ‘Data Governance solution’ because Data Governance is broader than just technology. It includes people and processes and may also focus on transactional data (i.e non-Master Data) where MDM does not play a part.  It’s more accurate to think of MDM as one of the key technology components of a Data Governance initiative that enables organizations to achieve their business objectives through the effective management and stewardship of Master Data.

Myth 8. We Have Implemented MDM. We are Done with Our MDM Project.

Fact: MDM should not be thought of as a project that is done and dusted once an MDM solution is implemented. It is often the case that new business requirements emerge, business processes evolve and new IT systems are introduced that need to be integrated. This means the initial MDM configuration and scope may change regardless of the initial purpose of the implementation. In order to deal with this effectively, organizations need to think of MDM as an ongoing discipline that needs to have executive-level support and is supported by a dedicated cross-functional team to ensure the organization continues to leverage the benefits of clean Master Data in new business applications, ERP migration projects, BI initiatives and trading partner collaborations across the enterprise. Having a dedicated MDM and Data Governance team also enables organizations to establish a repeatable process that helps drive cross-divisional alignment when additional business drivers emerge. Ultimately, the tangible ROI of an MDM investment considerably grows when organizations enhance the use of clean and reliable Master Data in many facets of their business.

Myth 9. MDM solutions cannot be implemented in the ‘Cloud’

Fact: Master Data is critical to an organization as it deals with core information about its products, customers, suppliers, locations, assets and employees. Organizations have long had reservations that such information can reside outside their firewall in somebody else’s data center. One obvious concern was security but there were also other open questions related to integration, performance and scalability that weren’t adequately answered by solution providers.

This has changed. An increasing number of MDM vendors now provide their solutions on the Cloud either using their own Cloud infrastructure or leveraging third-party Cloud computing services like Amazon AWS, Microsoft Azure and others. They also offer different hosting options whether it’s in a Public Cloud, Private Cloud or Hybrid Cloud model. Some MDM vendors have gone to great lengths to prove the security, availability, disaster recovery, scalability and performance of their Cloud infrastructure and that of their partners. Most have also addressed the question of integration by providing secure APIs and Web Services for near real-time integrations and file-based import/export capabilities for batch integrations of their Master Data. These trends along with the inherent benefits of Cloud services have led a growing number of organizations to deploy MDM applications on the Cloud. Organizations are seeing the benefits of reduced cost of IT infrastructure, greater agility and predictable annual subscriptions of their MDM Cloud applications and analysts are taking notice.

Myth 10. All MDM vendors have similar offering

Fact: When assessing the current landscape of MDM vendors, one can take the approach of categorizing them based on different criteria such as domain-focus, industry-focus, market-segment focus and cost of ownership. If we take the domain-focus, for example, MDM vendors can broadly be separated into three categories pertaining to how they approach mastering different types of domains (i.e. product, customer, vendor, location, asset, etc). The first category is ‘single-domain’ MDM vendors who provide solutions only focused on a single domain whether it’s a product, customer or supplier. While customers may get depth in functionality for a specific domain, they have no option to purchase a solution from the same vendor to deal with other Master Data domains. The other two categories are ‘multiple domain’ and ‘multi-domain’ MDM vendors as defined by Gartner. ‘Multiple domain’ MDM vendors have a solution for more than one domain but not necessarily in the same application or even on the same technology platform. This leads to having different data models, Business Process Management capabilities, user interface or integration framework for mastering one domain versus another. In this model, although customers may get MDM solutions for multiple domains from the same vendor, they often need to invest in additional technology and training costs to support multiple domains.

Finally, ‘multi-domain’ MDM vendors provide the ability to manage all types of Master Data in a single application. They often have a highly extensible and configurable data model to define any data type and related attributes. Business Process Modelling also tends to be highly configurable to support the unique needs of each data domain. The technology platform, user experience and core Master Data management capabilities are consistent regardless of the domain. From these vendors, customers get a one-stop shop to address their MDM needs and only incur marginal cost for technology and training when they add more domains. This often leads to lower overall TCO.

As mentioned earlier, the ‘domain’ angle is just one way of looking at solutions from MDM vendors. The reality is there is a high degree of variability between MDM applications in capability, industry depth, use case focus, deployment option and cost. It’s worth for organizations to look more closely based on the criteria that are most relevant to their specific business needs.