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.

I was talking with a sales person today who wanted help to initiate a dialog with a client that we knew had an MDM “issue”.  We explored several ways we could help the client with respect to MDM, and as a result of the conversation, the sales person came to a mighty conclusion: why is there not a simple, standardized, blue print for the client to explain to how to get started, and what the next 2, 3, and 4 steps should be?

This is a good question – but I had to explain to the rep what, to me, was obvious.  Each enterprise might end up with a vision and strategy for MDM that seems to look and smell like the next guy, but that is not really important.  What is important, and now clear, is that each and every enterprise starts their journey toward MDM, from a completely different place!  As such, there is no single blue print, but several, even many.  I explained that there were large patterns emerging, but these are today not detailed enough to provide individual blue print for each firm.

There are some typical places from where large clusters of firms have begun their MDM journey; here are some of them:

• Departmental Madness: Specific business leaders, perhaps VP sales and marketing, report that business performance is poor; initiatives to improve customers service, up-sell and cross-sell, are not delivering on their promise despite significant business and IT investment in new application and business intelligence software.  Root cause analysis shows that IT costs are higher than expected in support of increased data cleansing and integration routines; and the business says it takes too long to get the data to make the right decision.  This “departmental” cluster is complicated in that any number of departments might make the leap between the symptom (poor business performance) and cause (master data quality).  So this cluster is actually many different sub-clusters,
• The Unintelligent Business, or, ‘BI gone wild’.  This cluster has the common characteristic that each business meeting, that includes leaders from different parts of the business, spend more time arguing over the data, the source of the data, or the accuracy of the reports they each use, that business decisions are often left unmade, made with poor data, or elevated to senior management who have even less idea what to do about the decision.  Generally each stake-holder has developed, over some period of time, their own data source and this source is independent, and likely not integrated to any formalized information architecture in the business.  This emerged very often when senior executives encourage internal competition for resources and management attention, between departments, or business units.
• The Sunny ERP Uplands: A mid-size firm, in the specialty chemicals industry, is trying to wrestle with a migration from many legacy and custom made business applications to a single instance ERP strategy.  This is a “me too” strategy since the firms’ competitors seem to have done this already, and the firm believe that this is a necessary step in order to remain “in the game’.  There has been little thought to how ERP supports the firms secret sauce, business competitiveness, process automation, or process innovation.  IT has no idea where the master data is; who really uses it, or why.  There seems to be lots of data everywhere, locked up in applications that do not play well with others, will be ‘sunsetted’ over the next couple of years anyway, and bottom line – business and IT do not have a good working relationship.  IT is distrustful of the business – they do not think that the business really knows what it needs.
• The Kaleidoscope: A large, global financial services firm is trying to migrate hundreds of legacy and ERP applications across several regions. around the glob, over the next 5 or more years.  There are regulatory issues to cope with as there is an additional global BI strategy that supports financial reporting.  The final selection of two large ERP alternative vendor is about to be made; the business seems to be ignorant of the fact that compromises in each case will lead to different parts fo the business being serviced with innovative or best in class capabilities. 
• The Engineer: A large, European automotive parts supplier is being hit with two major issues: the need to reduce substantially its time to market for new parts; and increasingly demand and more complex requests from customers and partners for product related data.  The firm has invested in Product Lifecycle Management and this was thought to be the silver bullet to their product development needs; this did not prove to be the case.  While engineering received some good functionality to meet their design needs, the firm seems to be have been over-sold by the PLM vendor that implied that PLM supports the end-to-end lifecycle of the product.  The firm is now wrestling with how to manage information across the business, across PLM, ERP, SCM, CRM, Procurement, and other systems – including trading partners.

You might see aspects of each of these clusters in your business – and that just proves the point.  Every firm will understand and agree that there is value in having consistent master data (we can even agree that need the principles of MDM in the home – every tried trying to change channel without a good, clean program guide?), but the place from which every firm starts the journey is different, and infinitely complex. 

Company A – Two steps forward, One steps back

I met with a number of individuals that represented business and IT, across sales & marketing, operations, finance, IT, and BI.  The customer had an objective of formalizing their MDM strategy.  They reviewed several different initiatives they had underway:

• one focused on finance data consolidation (across multiple ERP systems)
• another focused on building a new “customer hub” for multiple CRM systems, including transactional, master and analytical data
• and a third focused on a data integration pilot that built data quality rules into several data integration flows to clean data up as it flows through.  

This firm also has a longer term ERP rationalization strategy underway.  Over several years they have grown through acquisition, and now represents 5 distinct businesses, in US and Europe, each with their own business systems but sharing common customers, and common suppliers.  

During the dialog the team of users realized that governance, process change, and organization change were keys to making MDM a living, breathing, sustained process.  The projects the team had described had no distinct MDM focus, even though master data was being touched over and over again, with each IT and business initiative.  But with now business sponsor, IT was not able to make MDM “stick”. 

Lastly, we explored why there had not been any MDM focus to date.  We learned that the firm, that is predominantly an information oriented company, had no Information Architect or defined information strategy!   This explained a lot.  Though the firm is profitable (the enemy of innovation), there was no single person or role looking at the overall strategy, let alone master data.  But business pressure was mounting that eventually brought enough users together to realize that MDM was going to be needed – so now the next step is first to establish a broader vision and strategy.

Company B – The Sunny Uplands

This firm is a large engineering firm that has also grown through mergers and acquisitions.  This firm also has several ERP systems, as well as large PLM components.  There are separate sales and marketing business units also.

This firm had developed a comprehensive information strategy even though they are a physical products company.  The products this company makes is very complex (ie engineered) and so a lot technical data is used to design and manufacture – and then support – the product.  This skill has led to a good understand of how to ensure data is maintained consistently, and made shareable. 

Additionally the firm also had developed a series of other master data oriented strategies, across supplier, customer, location, and also other data (called reference data) that looks and smells like master data but is not your typical objects (ie exchange rates, units of measure).

The firm had adopted Gartner’s MDM Maturity Model and compared and contrasted their maturity, across all key business units and departments, all master data domains and initiatives, and evaluated their current maturity against vision, strategy, governance, organization process, metrics, and technology.  The firm presented this information to us and was looking for feedback on the overall strategy: 

• How did the approach look?
• Would gaps in the strategy be found if they continued in this way?
• Were there any obvious gaps now?
• How does their status equate to industry norms?
• What else can they do to assure better success with next steps (execution)?

Bottom Line

These two stories were like applies and oranges – both firms have MDM aspirations, both know that MDM can help their businesses and both know that it is needed.  However, two very important take-aways came to me when I compared these initiatives:

• MDM can succeed in isolation to some larger, information management strategy (such as Enterprise Information Management) but it is real, real hard to succeed with MDM    
• Governance, process, and organization is far more important to MDM success then technology

Busy week – closing out an MDM Magic Quadrant; closing out the MDM Hype Cycle, as well as talking to some users about some complex MDM problems.  What else can an analyst ask for…

Certainly users have been trying to achieve “single view” for many years, before the phrase master data management was coined.  The problem of trying to maintain a semantically consistent definition of master data across the business has been a long standing desire for most firms.  It is because business (and to a great extend, IT also) has grown to be so complex, that since 2000 many firms have begun to look to specific tools to help.  

In my travels I speak with hundreds of clients each year, and on top of this, vendors provide numerous references.  Overall maybe 5% to 10% report that they have tied to build a legitimate, stand alone MDM technology themselves.  Almost all of these report that the effort is too great and too costly and hence they prefer now to look to specialists who live and die based on their MDM skills.  However, in 2008 I did meet 3 end users organizations that had really impressive MDM disciplines established, enterprise wide and/or globally, without externally sourced MDM technology.  So it can be done.  

Now back to the vendor briefing: This is a large business applications vendor that has a large client base that is virtually all heterogeneous in that they all have lots of different business applications.  The vendor has decided to build their own MDM capability – but it is not like any other MDM strategy I have seen.  The basic concept is that each business application that the vendor sells (and there many) is being extended in order to publish data and messages to a specific industry-neutral data model.  This data model operates as a clearing house; each application that links to a ESB will use the ESB as a massive message oriented clearing house for master data changes.  As a master data change takes place in one application, it sends the change to the ESB; the ESB maintains the rules over where the data needs to go.  

Most MDM strategies thus far have focused on some specific data repository that acts as the central clearing house and authoritative source of master data.  So after an hour I was left with the question – could an event-driven, message-based architecture, based on a centralized ESB yield the same business oriented value proposition (single view) without an MDM application?  I was not able to answer the question on the call; but I thought later and think that there is an answer.  This architecture could emulate an MDM implementation (a pseudo-registry style), but there is a much larger overhead; and the offering is far less “open” than the name implies.  So the applicability of this offering, in view right now, is very limited.  But at least it made me think about how MDM could be achieved without the technology we refer to as MDM today.  

Hopefully the vendor has the good sense to test the limits of their strategy.  And if it is found to be wanted – as I believe it is – they have the good sense to change it.

But as I read the book I was struck by two things: First, I had an experience years ago, upon leaving a firm I had worked for (manufacturer) I then spend several months afterward consulting for them.  I found the experience flattering of course, but the idea that came to me was this: Why was it that my previous employer did not listen enough to me when I was employed by them, but since I was now outside the firm, they would pay more than they did previously to get access to the same knowledge?  I then generalized the experience with the notion of “company IQ”.  As we each join, and leave firms, the overall company IQ changes.  This explains why, over many years, firms have to re-learn the stuff they learnt before, and since lost.  It explains why we each get asked to consult wit hour previous employers. 

The second experience followed on from the first.  Given that MDM is a relative new attempt at solving an old problem (how to sustain ‘single view’ of key master data assets across the business for any and all purposes), how long will it take firms to adjust their overall company IQ in order to make MDM part of the natural and standard processes of the firms?  Will most firms be limited by the current small pool of users that really understand what MDM means to their business, and will early adopter implementations start to fall into disrepute during 2009 as practitioners get lured away by bigger and higher paying opportunities?  How do firms embed these new processes into their standard practices? 

My guess is that a proportion of currently active MDM programs will suffer in 2009 as organizational IQ will fall with the exit of highly sought after resources that really understand MDM.  The only way to prevent the organization IQ from falling (as it relates to MDM) is to highlight those individuals quickly and ensure that they have what they need in order to keep them on board.  MDM is a key initiative, so the need to keep the knowledgeable resources is very important too.