On the one hand, Master Data Management (MDM) is everywhere. It seems wherever I travel to, someone has an MDM program, or a project (depending on their level of understanding of what MDM is). However, as I have blogged recently, it seems things are getting a little of out hand. All manner of discontinuities with MDM are growing – probably to due the growth in popularity for new shiny toys, and with the accompanying lack of education. MDM is not like “more data management”.
So there I was, sitting in front of a user, with representations from IT, ERP implementation, Program Management Office, and with business users representatives on tap. The message I heard was:
“ We have being doing MDM now for a year. We have come up against some challenges. Our master data hub has been implemented in the ERP system (i.e. same data model, so it is the same instance of the ERP system) but we are having to create additional copies, “off to the side”, to help extend the data model for other applications, outside of the ERP footprint. Help.”
This is a deceptively challenging situation, due to a coupe of issues with education that has failed:
- A data hub, if implemented within the confines of an ERP data model (i.e. identical so they are one, not side by side) is not, technically, MDM at all. It’s more akin to bastardizing the engine of a sports car and forcing it into the body of a tired old family saloon. I don’t mean to imply that ERP is old or tired; but that these are two (MDM and ERP data) different kinds of challenges that don’t naturally equate.
- Software vendors are using the term ‘MDM’ to mean, “anything related to managing data”. MDM is not that. If it where, why did we collectively come up the initiative?
The first item identifies poor design, and lack of understanding of what MDM is meant to be. It is poor design because the data model of a hub, designed to support MDM, should be independent of and supportive of any number (and in fact all) of business applications that need to share widely common and re used data. This should mean something:
- That ‘master data’ – the data in the MDM hub, is a sub-set of the data in an ERP system. A sub-set means that master data is LESS than the data in the ERP system. In other words the data in an ERP system should be based on master data but that there will be lots of other data in the ERP system.
- That the data model of the MDM hub will not likely match any one application data model – of necessity it will always be a hybrid – some attributes will appear in many if not most applications. But not all attributes in the MDM system have to appear in all applications. The point is that the master data is what links the core business processes (spanning applications). MDM is NOT the entirety of that data.
This first item is also related to a recent blog on the same topic: http://blogs.gartner.com/andrew_white/2013/04/17/we-are-only-half-pregnant-with-master-data-management/
There are a growing number of end user organizations that are trying to “master” as much data as they can in their MDM hubs. In some cases, the organization might be trying to figure out how to store Bill of Material on its product information hub. Another might be trying to store lifetime value (in terms of forecasted revenue) as an analytic within the customer master data hub. What are we doing, people?????? This is near madness. Just because a vendor or architect says we can, or could, does not mean we should. Also, just because it seems like a good idea at the time, don’t just “do it” without thinking through what you put into this position (and why such a decision could perpetuate the problem you are trying to solve).
I don’t mean to say that you should never deploy your hub “inside” your ERP. If the bulk of your master data is BORN and USED inside the one data model that is your ERP system, then that’s good. You don’t actually need an MDM hub at all though – you can use your ERP data model for that. Epicor has a data model for ERP that actually spans CRM, core ERP, SCM, Procurement and other processes. Vendors like SAP and Oracle do not have one data model for all those applications (actually they do, for smaller enterprises, or for some new ERP offerings) – since they have a lot of applications acquired or developed over the years. They have to “integrate” their applications (and for them, that does not mean via MDM, either).
So the working assumption I would want to use – until I know more about the business, is that the MDM hub, the master data model, is likely to be independent and outside of ERP. EVEN if there is a so named MDM-hub “inside ERP” because the vendor calls it that, does not make it MDM. It is just a local, ERP centric data hub that will be part of the overall MDM infrastructure. That is very different than saying, “it is the THE hub”.
And “ERP” hear is just a term to mean “an large set of applications that SHOULD share a common data model” so there are other such packaged, industry specific and development applications – on mainframes, cloud and so on. So please don’t get hung up on “ERP” and ERP vendors specifically.
Bottom line: Organizations are rushing into MDM without the right understanding in place. This is not a good thing – but certainly a sign that MDM as we see it in the market (MDM of Customer Data, MDM of Product Data) is firmly in the grip of the “trough of disillusionment” – a necessary stage of the Gartner Hype Cycle.
Read Complimentary Relevant Research
Predicts 2017: Artificial Intelligence
Artificial intelligence is changing the way in which organizations innovate and communicate their processes, products and services. Practical...
View Relevant Webinars
The Gartner Top 10 Strategic Technology Trends for 2016
Strategic technology trends are rapidly changing disruptive trends with significant potential for enterprise impact over the next three...
Comments or opinions expressed on this blog are those of the individual contributors only, and do not necessarily represent the views of Gartner, Inc. or its management. Readers may copy and redistribute blog postings on other blogs, or otherwise for private, non-commercial or journalistic purposes, with attribution to Gartner. This content may not be used for any other purposes in any other formats or media. The content on this blog is provided on an "as-is" basis. Gartner shall not be liable for any damages whatsoever arising out of the content or use of this blog.