The impact is that more information will be needed by manufacturers since consumers, and their agents (the retailer) will be asking for or consuming more of that data.  Perhaps more data will be delivered via changes in packaging and labeling requirements, from cases, totes, down to saleable items.  All in all – another identified beneficiary of MDM, and a sign of increased demand on mastering and governing product and related data through the value chain.

A magic quadrant, despite its name, is a whole less magic than its name suggests.  A lot of work goes into producing an MQ.  I just published on, an update to the Magic Quadrant for Master Data Management of Product Data, and my colleague John Radcliffe just published his update to the Magic Quadrant for Master Data Management of Customer Data.  Here is a quick summary of what I did:

• Initial review of the market, its current dynamics, trends – that lead to an hypothesis, based on interactions with users over the preceding 12 months.  This view or hypothesis is to be tested with the rest of the research process, and would be the basis for the Magic Quadrant note
• Vendor briefings with vendors in the MQ, and a whole lot of other vendors, that are not in the MQ, in order to get a wide view of what is happening from the vendor perspective
• 170 individual interactions with end users, via reference calls or survey feedback
• Pretty straight forward statistical analysis of the survey feedback; with some subjective analysis of additional data provided by users
• Building of the Magic Quadrant model, which is spreadsheet based, for each vendor individually, then for vendors in relation to each other, then at the market level
• Initial “sniff test” and then detailed consistency review of the analysis
• Revision to hypothesis, and revisions to the market overview
• Detailed write up for those vendors in the Magic Quadrant
• Peer review at Gartner spanning direct feedback in research community presentations, as well as detailed line by line and dot by dot feedback in our editing software
• Final “sniff test”
• Vendor “factual” review – to make sure no erroneous data or comments are included
• Editing, publication

So it is not surprising that analysts look rather tired and a little older once an MQ is published.  This takes me back to my soccer refereeing last weekend. 

Before a soccer match starts, both sets of parents are neutral – even positive toward the referees.  In fact everyone is very polite period.  Both sets of parents go out of their way to be nice to everyone.  But when that whistle blows, all bets are off.  As the first half of the game ends, it is very likely that one set of parents “love you” and the parents of the other team “hate you”.  This is a reflection in how the decisions went during the game.  Some decisions will be seen to favor one team, and negatively hurt the other.  During the second half the referees have every chance to now upset the previously happy parents with more decisions that less understood by the parents.  So by the end of the game everyone is upset with the referees.  This cycle repeats itself over and over, around the country (around the world!) every day, every weekend.  And its just like an MQ.

In this case, the sets of parents that represent the youth teams are vendors.  When the MQ process starts they are neutral – and they are very helpful.  As the MQ process concludes, it’s likely every vendor is upset at something.  Each vendor sees the market through their own, private lens – much as parents see the soccer match.  As with MQs, most vendors only have one or two lenses at most, referees and analysts get to see a whole lot more of the game and market – so are more experienced at looking at the whole.

The end of the game however is different.  At the soccer match you go home without any new friends.  With an MD, at least the end users, the primary consumer of the Magic Quadrant research, are very thankful for the work we do.  I just have to wonder what we do, as analysts, with the yellow and red cards we are so familiar with in soccer refereeing!

1. “XXXXXX currently utilizes a 5-digit internal product code field to identify product for ordering, sales, inventory, etc.
2. Question: How do other organizations like us address their product management, i.e. unique id, UPC Code, product catalog, etc.

This is not the kind of question I get, but I know from experience that this is a topic that attracts a lot of attention within end user organizations, specifically manufacturing and distribution.  When I worked in aerospace and defense (5 years), consumer goods (11 years), and household goods (3 years), I would participate in the annual process related to improving the use of product codes. 

After joining Gartner I even wrote a note (See Not All Enterprises Need Intelligent Item Numbers) in 2003 with colleagues of mine, Marc Halpern, David Hope-Ross, and Karen Peterson, on the topic.  It is now old and so “archived” yet the conclusions drawn remain valid today.  If my boss reads this he will politely suggest that I refresh the note; psychology tells us that when clients read notes from 2003 they assume that it must be out of date.

From memory, I played out the following scenario almost every year, often times at the same organization, only impacted slightly by changes in management (that kept forgetting the past).  We start with the assumption that we ask ourselves, “Ah, we have a number scheme – now what?”

1. Recognition that he number scheme is not perfect, not consistent, even corrupt, then
2. Recognition that the coding system is in fact an impediment to many business (not just or even IT) initiates
3. Then efforts are established to reinforce the broken process, try to clean the data up
4. This takes too long, so spend another cycle trying to think up a wholly new process
5. This becomes like volunteering for a frontal lobotomy, so that project slowly retreats into the shadows
6. Conclusion made: Organization is unique, different, complex, and since no 2 folks could ever agree a solution, everyone just “carries on as before”
7. Process repeats a year later under different management

 Sound familiar?

Bottom line: Wal-Mart will be simplifying its supply chain (removing layers, and non-value-add assets) and also standardizing and rationalizing core processes.  The organization will have to focus on achieving, and sustaining, “single view” of supplier and product data.  MDM will be powering these cleaner, simpler business processes.

Over the last 5 or 6 years this focus has broadened in scope and has since spawned other drill down topics, such s Procurement MDM which has, itself, split into MDM of Supplier data and MDM of Purchased Part.  Holistically though, MDM of Product Data generally means mastery of “thing”.  Thing is a kind of ‘province’ in that most “things” have common characteristics or challenges; and characteristics and challenges across ‘provinces’ are not similar (think customer/supplier master data).

Well this forward looking user was just starting to roll out an MDM application (single solution, single vendor) for both buy-side product data as well as sell-side product data.  I say this is forward looking because to date most users, if they have gone this far, have assumed that a different solution and possibly different vendor, are needed for each.  Sell-side MDM is much more mature – the mastery of the data was separated from the business applications that created – and consumed the data – 6 or more years ago.  For buy-side, the procurement and spend data management vendors have not yet “let go” the data and so users on the buy side assume that procurement vendors and spend data management vendors are also providers of MDM of purchased part solutions.  Like sell side, the separation of the data and the application will take place – it is just taking a long time.

So this client has taken a leap of faith – they hope several things:

• The MDM vendor can in fact cop with the complexity of requirements for both buy and sell side
• The business applications and analytics solutions, used by business users, to guide selling and buying decisions, will easily integrated with emergent MDM infrastructure
• IT can create a new discipline that, when needed to develop and deploy new business applications and analytics, they do NOT develop or deploy them in the MDM application itself, but as part of the business application and analytics layer.

When users ask for more analytics and business process support the natural and obvious choice will be to “add it to the MDM application”.  After all (the logic will run), that is where the really good clean data resides.  But in adding business application and analytic logic to the MDM infrastructure layer, IT would be reverting back to what it has been doing for the last 20 years – that created the mess in the first place that led to the conclusion that some change in “Integration” needs to take place!

There is a trade-off that emerges: MDM leads to the separation of master data from business application/intelligence.  IT is shifting from 20 years of vertical silos (application plus data) to a new framework of horizontal services (application, analysis, information management).   In the process, and it is a long process to get from a) to b), the IT stack does get more complicated.  So short term costs could increase, flexibility may not accrue immediately, and complexity may increase also.  The pressure to get MDM firmly established for all important master data objects needs to be kept up else the business will not see the benefits and the risk is that MDM will fall from favor for a traditional (silod) business-as-usual approach.

So it will be an interesting time for this user: Great vision, great strategy, hopefully not too far ahead of where the vendors can meet the user needs.  I will be watching very closely – as will many of you, I know.

Preparations this week focused on getting our last presentations into our editing machine such that they can be formatted, made consistent, and cleaned up for public consumption.  Once the presentations are completed we then begin the slow process if distilling from the key messages, and creating a body of work that is to be published over the next couple of quarters.  Our Summits force us to put on paper all the good, new ideas and content that we have explored with users recently that has not hitherto been published.  These Summits, though a lot of work, are a great way to keep forcing our brains to dump content onto paper, thus freeing up more space for the next set of client interactions.

I had some interesting inquiries this week.  Here is a smattering of the more notable:

On Monday I had a real interesting call with a large industrial end user client that wanted to explore options for – wait for it – “cloud based MDM”!  Well, I knew I was in for an exciting conversation already since that is an odd topic.  I have blogged on this before(SaaS moves the process boundary, does not necessarily change the process, and can make integration of master data more complex); there are not real cloud based MDM offerings today, and really only a very small handful of end users have asked about this – more for interest than anything else.  Only one serious vendor has talked to me about this opportunity – and a credible vendor at that.  But, as I have said before, this is a complex topic.  On the one hand it makes sense that aspects, even all of MDM, should/could go outside the firewall, but the costs to move to that state increase for each and every object.  Those costs relate to integration, synchronization, management and so on.  Application infrastructure gets more complex as a result – until and if enough master data exists outside the firewall at which point the costs, and complexity, fall.  But there must be a tipping point at which this takes place.  Question is – which industry, which business processes, and which master data, are close to that tipping point?  

On Tuesday I had a real good call with an energy user.  This was a large organization with a strong IT shop; I spoke with several senior architecture folks were trying to invigorate their overall information management (IM) strategy.  They knew that MDM played a role in overall IM but they were not totally clear what the relationship was; and they also had an issue with “getting started” – how could they get interest from the business to help them with their IM strategy?  We explored MDM and its connections to IM, as well as to Business Intelligence and Business Applications, and very quickly the client realize that MDM is a great place to start their IM invigoration efforts!  I suspect that I will be talking with them a few times in the next few months to help guide them through their MDM launch.

On Wednesday I presented on MDM vendors to our MDM Special Interest Group (SIG) that is part of our EXP program’s Best Practice Council.  I highlighted the lenses through which we look at the MDM landscape (data domain, use cases, industries) and then talked about how the vendors align both in terms of capability, versus direction.  Many vendors are “good” at one thing/area, and have plans to be “good” at many others.

On Thursday I had a call with an end user firm that I know very well.  In a previous life I worked for an organization that had a business relationship with this client, so I knew something about their business.  They are in consumer goods/fine chemical industry segment, and they are struggling with one aspect of MDM – that being the link between MDM and product design/development, clinical trials, and operations/manufacturing.  The client has a lot of experience with operational MDM for traditional objects, such as customer and product, but this aspect of MDM was more focused on multi-enterprise considerations of sharing complex and confidential information that drive product design, development and acceptance.  

On Friday I joined one of our more interesting virtual research communities (B2B) that span several other formal communities, to explore how business to business is evolving.  My interests, including Supply Chain Management (SCM), concerned both the drivers for why business processes are moving outside the firewall, and with Master Data Management (MDM), what are the barriers and inhibitors to that movement. By exploring one specific phenomenon, related to e-Invoicing, we concluded that we need to identify scenarios by which users can evaluate a longer term B2B strategy.  You might not see the connection – between e-Invoicing and long term B2B strategy – but it is there.  More on this later…

So it was a great week – brimming with client interaction, and research production.  Time for a rest, and a cold one.  Have a good weekend.

But the funny thing about this Magic Quadrant is that it is poorly named!  Despite the name, “product data”, we really mean, “thing data”.  Most MDM of Product Data solutions are being deployed in places where firms have a need to master products, items, parts, tools, assets, services, and other “thing” kind of objects.  As such, the Magic Quadrant could be called, Magic Quadrant for MDM of “thing” data.  However, that would not really sell (or be that meaningful to the lay reader.

Likewise, John Radcliffe’s Magic Quadrant for Master Data Management of Customer Data is also poorly named.  Most users that implement these technologies are mastering customer, partner, account, supplier, and organization.  As such, this market segment could be called Master Data Management of ‘party’ data but again, that won’t sell or fit easily with the simply way users look at this stuff. 

The other segments that continue to emerge in MDM land include:

• hierarchy (relationship data that relate one object to another, used most often in reporting systems, but very often sourced in business applications; examples could be customer territory and account relationships; product category, product type codes)
• location (not often of primary concern when users think of MDM, but increasingly is of secondary interest to users once something like customer or product is mastered)
• procurement (the link between supplier and purchased-part master data, and the analysis that helps business make smarter decisions in procurement is clear, but the management/governance of that data is only slowly being externalized (ie MDM) from under or within the business applications in this domain
• asset (for certain industries, such as oil and gas, utilities, energy, and telecommunications, assets are important to the business and so asset master data and its governance is increasingly being called out as a specific focus

Hopefully the Magic Quadrants are helpful to you in evaluating technology providers – as you consider mastering “party” and “things”.