Blog post

Enterprise Information and Master Data Management (MDM) Summit Q&A

By Andrew White | February 07, 2015 | 0 Comments

Omni ChannelMulticommerceMDM-Summit-NAMDM SummitMDMMaster Data ManagementInformation ArchitectureEnterprise Information Management (EIM)EducationE-CommerceCRMApplicationsApplication ArchitectureMDM of Customer DataMDM of Product Data

We have in hand a number of questions from attendees from last year’s summit that were handed in at the closing keynote.  We have also received questions from those inquiring of this year’s event in London and Las Vegas, and we also pooled our thoughts from a number of the more common questions today we see from. I am posting a series of these questions, along with an answer.  Many of these questions are listed “as received”.  I hope you enjoy them.

  1. From a vendor perspective, why are multi-domain MDM solutions so challenging?  I.e. Technical/process problems?  Or marketing problems?  Other?
    • Though the range of technologies needed to support MDM (e.g. data quality, data model, dashboard, workflow, analytics, integration etc.) look the same in name, the reality is that there are differences. The differences in the technologies needed for different data domains such as customer and product, as well as additional differences that are specific to industries even for the same data domain, result in different capabilities.  For example for customer data you most often need a data quality capability such as entity resolution. For product data the more common data quality capability you need is semantic and/or text string parsing.  Vendors have addressed the markets in different ways to seek competitive positions.  Thus specialization leads to a solution for fitted for one data domain and/or industry that is less competitive in another.  To try to put all the capability, all the intellectual property, and all the industry support, into one single product or solution is just far fetched.  There are some end-users who requirements are not that complex, and as such they may use a product that does actually support several domain, but these are still relatively rare.
  2. What are your thoughts on product data solutions for e-commerce?
    • This is a complex question, really. Some of the MDM of product data vendors have focused on customer-facing business processes, such as those related to order to cash and e-commerce, or even omni-commerce.  Some of these solutions have therefore been asked by end users to store much more than structured product data.  What vendor do you know ever says, “No, I can’t do that”?  At the same time, some MDM of customer data solutions have been deployed in a different part of the same organization, focused on customer data.  With big data there is even more need to integrate and unify the customer, prospect, product and sentiment data.  Thus MDM is at the center of that conversation too.  Not an easy one to answer definitively.  Hope this helps identify some of the trends.
  3. Magic Quadrant for data model management?  Vendors ER studio, Power Designer, ERWin etc.  Criteria?  Repository power, version control, meta-data, cross-platform support?
    • Great question. The challenges here are several.  This is not really one market.  A lot of the vendors or tools that did some of these capabilities have been acquired, and the capability has been rolled up into another product and so into another market (and so Magic Quadrant) as a feature.  Some of the technologies are widely re-usable for (say) MDM, application integration, B2B, data migration and so on.  Thus the use-case differs greatly too.  So there are several different capabilities that architects and designers use, and increasingly some of this data is needed by governance and stewardship users in line of business.  So we do watch the space and if we see coalescence of demand (from you) and a growing set of interchangeable, competing offerings from vendors, you can guarantee we would cover that with a Magic Quadrant.
  4. I keep hearing that “the business” needs to own the rules, the process, be the data stewards.  So what do you do when your sales team just wants to sell and they believe MDM and data quality is an IT problem?
    • This is one of my favorite questions. It’s the wrong kind of question though, and the fact that it arises suggests that MDM (and data quality, for that matter) is not understood by those business people the question refers too.  When I was a Supply Chain planner at Elizabeth Arden I was the informal information steward.  I accepted the role unofficially, from my peers – I was a citizen steward.  Whenever one of our business processes, such as planning a new product, or revising a production run for a new promotion, was held hostage to bad data, the other business users would come to me to “fix it”.  I was the only one that had an understanding of the IT systems and apps we were using and I knew how to get things fixed.  In this case the business (I was representing the business) knew the value of information and we did the work.  This is the same for sales.  Unless the sales team understand what bad data does to their sales process, they won’t care for data.  So the question should never come up – if the right education is established.
  5. In terms of architecting the information environment, how do organizations understand the requirements for MDM and CRM tools?  What is the difference between the two?  When would I choose one over the other…or do we need both?
    • This is quite a broad question – given that MDM and CRM are two very different things. CRM is a business strategy that is focused on understanding and servicing a total relationship with customers.  This may need a CRM application, and each one may come with its own customer master file.  MDM is a program that assures consistency of master data (not all data) – such as customer or product master data. MDM programs are supported by MDM solutions that bring with them a tool set to help reconcile and manage those disparate versions of master data – in this case customer data across all your CRM apps, suites, and cloud based apps, to ensure you only have one version of customer across them.   From a business perspective you need CRM (if you sell to customers) and MDM.  That is not the same as saying you need a CRM app and an MDM app.  The degree to which you need technology cannot be answered in this format – it requires a detailed understanding of your current business, application and information environment, a view of where those are headed, and a clear view of what business goals are to be exploited and/or maximized.

Comments are closed