by Andrew White | January 13, 2016 | Comments Off on Enterprise Information and Master Data Management Summit 2016 – See You There?
Last year in anticipating of the Summit series I posted some outstanding Q&A to cover some questions I had received previously or in the run up to the summit. I have some more for you this year (below). I would love to meet you and answer any questions you might have on Enterprise Information and Master Data Management.
For Enterprise Information and Master Data Management (and the new CDO “day”): Texas, March 16-18, 2016, and London, UK, March 2-3 2016. And while you are there, why not stay the full week for a good dose of Business Intelligence and Analytics to leverage the trusted data you just governed: Texas, March 14-16, 2016 and London, UK, February 29-March 1 2016. See you there?
- Data quality Magic Quadrant. Can you speak more on emerging offering around “what should I clean?”
- The “what” should you clean really depends on “what” is important to your organizations. For example I would suggest NOT trying to clean up supplier master data to help with “single view of supplier” in support of a spend reduction program if, at the time, the business has fat margins and is focused on growing into new markets. I would however suggest interrogating the quality and consistency and impact on customer, location, market, brand and product data for that same organizations. So the ‘what’ you should consider for cleaning up should always be tied in some way to an identified business outcome. If there is no outcome in mind, and no business sponsor in view, don’t try. No one will thank you.
- Please elaborate concept of virtualization of data in MDM. Thanks.
- This is both a simple and tricky question. Virtualization itself is a simple concept. Data is “virtualized” in that a copy of the data is rendered elsewhere from where it persists. This data is not duplicated – so it is representation of the ata. In some ways the registry implementation style of MDM is a form of virtualized master data – but that is a bit of a stretch. I think it’s fair to say that it is possible to virtualize data as part of a broader MDM program, especially as it relates to the initial setting up and evaluation of sources of data for system of record consideration. But once MDM is implemented there is no virtualized data – the data is actively governed – that is the whole point of MDM. Virtualizing the results of an MDM program may help someone else who cannot integrate to the MDM hub – that’s a possibility….but very manual I think.
- An MDM project requires a mix of ETL, DQ, and potentially one or more MDM domain – how do clients navigate the multiple MQs?
- With difficulty in some cases, and easily in others. For example, the vast majority of end user organization actually only tackle one of the larger domains at a time, that is to say either a customer oriented domain or a product oriented domain. Trying to do both at the same time would likely suck up too much of the life blood of an organization that it won’t be able to do its normal job. Even for each of these large domains there may still be other “multidomains” though often related to the single larger domain. For example with customer master data you may still include location data. This would still be multidomain MDM technically but the main complexity derives from the customer data domain (in most cases). For all forms of MDM there is a need for some common capabilities like ETL, DQ and so on. They need to be selected as you go, taking into account longer term needs to help make acquisition efficient.
- Should we focus on a single vendor for each tool or go for best of breed? Elaborate.
- This is similar to the last question. The truth is that you need to be think of two lines of reasoning. First, what is the source of complexity in your information based systems? Is it derived from one kind of master data, or several? Are the degrees of complexity equal? Do these sources of complexity hold business process outcome improvement hostage? This line of thinking will lead to a conclusion that one or more data domains need to be addressed – and this might mean MDM. Second, what is the budget window, and risk propensity of the organization? If you can budget smart and can look ahead more than a year, you might consider evaluating a vendor on its ability to meet current and future MDM program needs. However, most end user organizations do not do this. They select one vendor for one domain (with a real evaluation) and just accept that the same vendor can meet the other data domain needs later based on a verbal promise. Sometimes this works out. Sometimes it works out with a different product from the same vendor. Sometimes it doesn’t work out. Users should do proper evaluations for what it is they are buying/licensing.
- Thoughts on finance master data Management vendors?
- There aren’t any, really. Well, not that I know. In truth the chart of accounts are the main object of concern and most organizations have used their GL systems to ‘master’ CoA. In the case where there is some M&A activity, one or other GL is used to consolidate the other. Given the narrow focus of the master data there has been little market acknowledgement of need to master such data outside of the application that originally authored it – unlike customer and product data.
View Free, Relevant Gartner Research
Gartner's research helps you cut through the complexity and deliver the knowledge you need to make the right decisions quickly, and with confidence.Read Free Gartner Research
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.